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

Transcriptie

1 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 is een ingenieursdiscipline die met behulp van welbepaalde (beproefde en minder beproefde) systematieken en werkwijzen tracht te komen tot betere software en processen voor het ontwikkelen, implementeren, testen en onderhouden ervan. 1.2 Klassieke levenscyclus Het begrip klassieke levenscyclus heeft een weerslag op alle fasen die de software doorloopt vooraleer deze uit productie verdwijnt. Deze fasen komt men tegen in de omschrijving van het watervalmodel Watervalmodel Een lineaire opvatting van software development. Dit houdt in dat de software 5 fasen doorloopt: 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 (cfr. UML) 3. Implementatie: het eigenlijke programmeerwerk 4. Test: de software dient uitvoerig aan tests te worden onderworpen voorafgaand aan de integratie en in gebruikname 5. Onderhoud: al het werk dat wordt verricht na het in productie nemen van het eindproduct Figuur 1: Een illustratie van het watervalmodel

2 Oplossing examenvragen Software Ingenieurstechnieken 2 Indien er voldoening is over het gedane werk, wordt de fase afgesloten, eventueel met een rapport en de nodige bureaucratie. Het voordeel van het watervalmodel is dat het een duidelijke aflijning biedt van de verschillende te doorlopen fasen, ook voor niet-ontwikkelaars (klanten en management). Een nadeel is echter dat dit model uitgaat van weinig of niet veranderende vereisten. Eventuele veranderingen - hoe zwaar en moeilijk ook - dienen opgevangen te worden. Om met deze nadelen om te gaan, bestaan er ook lichtjes andere varianten: er kan een terugkoppeling zijn van elke fase naar de eerdere fase en aldus is het afsluiten van de fasen niet zo definitief als het oorspronkelijke watervalmodel de fasen kunnen elkaar overlappen (dus deels simultaan gebeuren) Prototyping Prototyping is het maken van een vroegtijdige versie van de software voor demonstratiedoeleinden. Kadert meestal in de implementatiefase van een andere ontwerpmethodologie. Soorten: Throwaway: helpt vereisten te begrijpen en/of bij te stellen kan niet evolueren naar leverbaar systeem Quick and Dirty: snelle versie van een systeem dat later tot iets aanvaardbaar gewijzigd wordt risico: 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 (deel van) een systeem tonen van sleutelelementen voor implementatiefase ontdekken van functionele eisen, rekening houdend met budget evolueert naar leverbaar systeem Voordelen: betere interactie met de klant (eisen kunnen doorgrond en bijgesteld worden) detectie van onvolmaaktheden of andere/verkeerd begrepen eisen spaart tijd en geld uit indien dit gebeurt in een vroeg stadium. Nadelen: het is niet mogelijk alle gebruikers volledig tevreden te stellen prototype kan aandacht afleiden, waardoor te weinig tijd besteed wordt aan analyse risico op levering van lagekwaliteitssoftware (te weinig doucumentatie, te weinig gelden tijdsinvesteringen als prototype als iets definitiefs wordt gezien) risico op voortwerken aan prototype terwijl eerder de beslissing moet genomen om opnieuw te beginnen (overevolved prototypes)

3 Oplossing examenvragen Software Ingenieurstechnieken 3 prototype hoort snel overzicht te bieden: te veel moeite aan prototype kan een bron van geld- en tijdverspilling zijn Besluit: vooral te gebruiken voor: een beter begrip en een eventuele bijstelling van eisen en specificaties het ontwerpen van GUI s het uitproberen van de mogelijkheden (sterke en zwakke punten) van een technologie 1.3 Iteratieve levenscyclus Dit is niet expliciet te kennen, maar dient enkel als situering van de informatie over het spiraalmodel. De iteratieve levenscyclus houdt in dat projecten worden ingedeeld in kleinere mini-projecten. Deze worden uitgewerkt en indien nodig overgedaan tot men tevreden is met het resultaat. Na elke voltooide iteratie krijgt men een nieuwe versie van het product (iteratief=evolutioneel=incrementeel). Voordelen: kosten- en tijdsefficintie, want bij onbevredigend resultaat moet slechts de iteratie overgedaan worden en niet het hele project minder risico dat projecten niet op tijd af geraken want (grote) problemen meestal vroeg gedetecteerd boeken van resultaten in redelijk korte tijd en aldus makkelijker om snel bij te sturen Spiraalmodel Dit is eigenlijk eerder een metamodel: het kan alle andere modellen bevatten Het spiraalmodel bestaat erin dat volgende stappen telkens herhaald worden: 1. planning 2. risico-analyse (resultaat is altijd: go/no go) 3. engineering: software-ontwikkeling 4. evaluatie door de klant Bij de risico-analyse wordt doorgaans - om begrijpelijke redenen - het grootste probleem als eerste in acht genomen. 2 Wat zijn de belangrijkste conclusies uit het CHAOS-rapport? 2.1 Statistische studie Nota: Success = project is gedaan op tijd, met het voorziene budget en met alle features Chalenged = project is overtijd en/of over het budget en/of niet alle features geïmplementeerd Impaired = project geannuleerd

4 Oplossing examenvragen Software Ingenieurstechnieken Success rates 16,2%: success 52,7%: challenged 31,1%: impaired 94% van de projecten herstart 1 of meerdere keren meer success bij kleine bedrijven dan bij grote Tijd, kosten en totaal aantal verwerkte features Cost overruns Vaststelling: hoe groter het bedrijf, hoe kleiner de cost overrun (meer budgetten beschikbaar?). grote en middelgrote bedrijven: rond de 180% kleine bedrijven: 214% Time overruns grote bedrijven: 230% (moeilijkheden met grote schaal?) middelgrote bedrijven: 202% kleine bedrijven: 239% Aantal geïmplementeerde features globaal gezien: gemiddeld 61% van de features raakt geïmplementeerd hoe kleiner het bedrijf hoe meer geïmplementeerde features Over mislukking en succes Top 3 redenen success 1. betrokkenheid gebruikers 2. steun van management 3. duidelijke eisen en specs Top 3 redenen challenged 1. te weinig betrokkenheid gebruikers 2. vage eisen en specs 3. wijzigende eisen en specs Top 3 redenen impaired 1. vage eisen en specs 2. te weinig betrokkenheid gebruikers 3. te weinig middelen Mening over mislukkingen t.o.v. 5 en 10 jaar geleden: meer faling t.o.v. 5 jaar geleden: 48% meer faling t.o.v. 10 jaar geleden: 46%

5 Oplossing examenvragen Software Ingenieurstechnieken Case study Impaired Department of Motor Vehicles in Californië (registratiesysteem voor kentekens) slecht intern beleid onduidelijke eisen slechte planning American Airlines (autoverhuur- en hotelreservatiesysteem) bemoeizuchtig management onduidelijke en wijzigende eisen te weinig betrokkenheid gebruikers Success Hyatt Hotels steun van management duidelijke eisen goede planning kleine mijlpalen Banco Itamarati goede planning competent personeel steun van management Top 5 factoren voor succes volgens case study Onderzochte bedrijven mochten punten geven aan factoren die ze belangrijk achtten. 1. betrokkenheid gebruikers 2. steun van management 3. duidelijke eisen 4. goede planning 5. realistische verwachtingen 3 Welke fasen kan men bij project management onderscheiden? Bespreek deze kort. 3.1 Initiatie acceptatie: beoordeling op basis van morele en praktische redenen specifieke, meetbare en realistische doelen verwachtingen van klanten en management definiren scope inschatten (risico s en beperkingen) regels, wetten, maatschappelijk,... elektriciteitswerken, failliet leverancier,... beperkingen mensen en budget

6 Oplossing examenvragen Software Ingenieurstechnieken 6 technologische risico s: genoeg mogelijkheden met gebruikte technologie? selectie teamleden: verschillende persoonlijkheden, kennis, vaardigheden desnoods uitbesteden aan consultants 3.2 Planning evenwicht tussen resultaten, tijd en middelen opdelen in taken gebruik van meetbare mijlpalen (netwerkdiagramma) vereiste kennis en juiste aantal mensen voor elk deel 3.3 Uitvoeringsfase leiden van team communicatie tussen teamleden: vergaderingen,... communicatie met management en klanten: rapporten,... oplossen van problemen/conflicten zorgen voor voldoende middelen 3.4 Controle afwijkingen van plan vaststellen plan bijsturen behandelen aanvragen projectwijzigingen beheer van middelen: eerlijke verdeling over subprojecten, aanvraag voor meer indien nodig eventueel terug naar planning 3.5 Afsluiten wat bereikt? ontmantelen team leren van ervaring bespreken projectverloop met teamleden en/of management schrijven rapport 4 Wat zijn de gouden regels voor een projectleider? 4.1 Consensus zoeken voor projectresultaten duidelijke doelen consensus tussen management, team en klant 4.2 Zoeken naar beste team gewillig met juiste kennis

7 Oplossing examenvragen Software Ingenieurstechnieken Goed plan maken en onderhouden compleet gedetailleerd toepasselijk 4.4 Nodige middelen verkrijgen Onderhandelen wat wordt uitgevoerd indien te weinig 4.5 Zorg voor realistisch schema 4.6 Niet meer doen dan nodig/mogelijk Moet duidelijk zijn voor iedereen 4.7 Hou rekening met menselijkheid teamleden Succes project is sterk afhankelijk van mensen 4.8 Formele en Blijvende steun van management verwerven Dus: goed kunnen communiceren 4.9 Bereid zijn aanpassingen door te voeren onvoorziene omstandigheden: computerpanne, waterschade nieuwe informatie, nieuwe tool nieuwe eisen van klant 4.10 Informeer de mensen If they know nothing of what you are doing, they suspect you are doing nothing. (Graham s Law) 4.11 Bereid zijn nieuwe zaken uit te proberen Alle projecten verschillen, wat een statische aanpak vrij zinloos maakt Leiderschap voor sommigen hard werk plannen, opvolgen, controleren project bron van wijsheid en steun geen dictator, maar teamlid

8 Oplossing examenvragen Software Ingenieurstechnieken 8 5 Bespreek de doelstellingen van projecten. wat en voor wie? duidelijke omschrijving goed overbrengen consensus: iedereen akkoord goede criteria om eindresultaat te beoordelen specifiek realistisch duidelijke einddatum/deadline meetbaar: klaar, kwaliteit overeenstemming (met opdracht?) verantwoordelijkheden voor bereikte doelen 6 Wat zijn taken en hoe kaderen zij binnen een project? 6.1 Definitie 1 geheel moet in schema passen behoefte aan een welbepaalde middelen en mensen kleinere, gedetailleerde en duidelijk afgelijnde deeltjes van een project meetbaar 6.2 Hoe kaderen binnen project? identificeren logische volgorde interferentie van taken? beoordelen/controle van nodige werk aan te raden een bepaalde verzameling taken af te sluiten met een mijlpaal mogelijkheid om een Gantt chart of een netwerkdiagram te gebruiken om taken voor te stellen 7 Welke conflicten kunnen tijdens het verloop van een project opduiken? niet achter zelfde doel staan: misverstand/weigering? taakbeschrijving niet specifiek genoeg administratie: aantal + vorm rapporten opletten hoe geheime informatie verspreid wordt teamleden weten niet goed wat ze moeten doen: durven ze het vragen? technologische onzekerheid verdeling taken: bvb. saaie taken, (wie doet) leiding subgroep te weinig tijd persoonlijke conflicten

9 Oplossing examenvragen Software Ingenieurstechnieken 9 8 Wat is UML? geef ook een lijst van de verschillende diagrammen met een korte uitleg. Afkorting: Unified Modeling Language Wat? verzameling van visuele modelleertalen (software-ontwerp), uitgewerkt door Object Management Group 8.1 UML 1.0 (1997) Het lijkt belangrijker te focussen op versie 2.0, aangezien die een pak uitgebreider is. 8.2 UML 2.0 (2003) Structuurdiagrammen Class Diagram: toont de klassen van een systeem, hun attributen en de relaties Composite Structure Diagram: interne structuur van klasse of component Component Diagram: fysieke componenten en afhankelijkheden Deployment Diagram: run-time configuratie van applicatie Object Diagram: relaties tussen objecten Package Diagram: afhankelijkheden tussen packages (groeperen klassen) Gedragsdiagrammen Activity Diagram: modelleren van processen Use Case Diagram: eisen vastleggen, communiceren State Machine Diagram: levenscyclus van 1 object Interaction Diagram: Sequence Diagram: samenwerking tussen klassen Communication Diagram: samenwerking tussen klassen Interaction Overview Diagram: activity diagram dat interactie modelleert Timing Diagram: interactie tussen objecten in de tijd 9 Waarmee moet men rekening houden bij het ontwerp van een User Interface? gemakkelijk te leren eenvoudig te gebruiken logisch en consistent vergevingsgezind: undo-functie? dialoog tussen mens en machine diversiteit van mensen niveau van kundigheid nieuwelingen: weinig of geen semantische en syntactische kennis redelijke semantische kennis: occasioneel gebruik van programma, maar moeilijkheden om syntactische kennis op te roepen frequente gebruikers: zoeken naar snelkoppelingen en verkorte interactiemethodes commando s! persoonlijkheid

10 Oplossing examenvragen Software Ingenieurstechnieken 10 cultuur (Europeanen gaan anders met computer om dan bvb. Amerikanen) lichamelijk: rechts-/linkshandig/gehandicapt voortbouwen op ervaringen en vertrouwdheid van de gebruiker gebruiker niet verrassen betekenisvolle feedback bij fouten en contextgevoelige hulp reactie systeem niet te lang wachten vooraleer te reageren geen te korte reactie (kans krijgen om te zien) tonen van informatie enkel relevante informatie standaard afkortingen, benamingen, verwachte kleuren beste vorm (grafieken, tabellen,...) tekstuele info duidelijk: hoofdletters, indentatie, tekstgroepering verschillende vensters voor verschillende info user input beperk aantal inputs beperk typen eenheden zelf voorzien indien gehele waarde, niet vragen om XX.00 in te typen default waarden voorzien bij destructieve acties standaard muis op Cancel plaatsen geen info opvragen die berekend kan worden consistentie user input (tekstgrootte, kleur,...) verschillende mogelijkheden voorzien zodat gebruiker kan kiezen geen sequenties opdringen vroeger niet-relevante commando s uitschakelen, nu: laat controle aan gebruikers over help voorzien voor commando s en inputwaarden commando s geven snellere interactie voor oudere frequente gebruikers voor elke menu-optie een commando? letten op vorm en parameters van commando hulp voorzien bij vergeten commando ondersteunen scripts/gepersonaliseerde commando s efficiëntie personalisering layout standaardisering: bvb: Open, New en Save in menu File 10 Hoe kan men goede programmacode schrijven? 10.1 Herbruikbaarheid gebruik van kleinere delen snellere debugging abstracte datatypes, bibliotheken,... enkel coherente delen bij elkaar, anders splitsen methodes meer dan 1 pagina? opdelen herbruikbaarheid

11 Oplossing examenvragen Software Ingenieurstechnieken 11 consistentie (cfr. C: puts (met \n) vs. fputs (zonder \n)) controles scheiden van berekeningen alle input dekken zo algemeen mogelijk geen globale info, maar parameters en attributen geen modes gedrag van functie liefst onafhankelijk van context 10.2 Uitbreidbaarheid objectgeoriënteerd abstractie/inkapseling mogelijk maken dat 1ste klasse operatie van 2de klasse kan bereiken, maar niet operatie van een 3de klasse tegelijk. als nodig doen vanuit 2de klasse. overerving van functionaliteit 10.3 Robuustheid geen op voorhand gedefinieerde limieten (dynamische allocatie) beschermen tegen ongeldige user input check actuele parameters bij publieke operaties foutafhandeling debugging en performantie-monitoring voorzien omgaan met schade: forward error recovery: fout herstellen en gewoon doorgaan met programma (vooral verwachte fouten: deling door 0, niet-bestaand bestand openen,...) backward error recovery: periodiek opslaan van systeemtoestand zodat kan worden teruggegaan (vooral onverwachte fouten: crash, bug) n-versie programmeren: meerdere versies van systeem door onafhankelijke teams ontwikkeld, meerderheid beslist welke best is: oneven aantal versies met verschillende teams met verschillende methodologieën op verschillende lokaties assertions: condities op data die gecontroleerd worden. In sommige talen runtime gecontroleerd, maar in meeste talen soort commentaar. preconditie postconditie loop invariant(bij lussen) class invariant (relaties tussen attributen) 10.4 Verstaanbaarheid eerst ontwerpen, dan coden zelfde namen als in ontwerp goede, duidelijke namen uniforme manier voor naamkeuze namen voor semantisch operaties

12 Oplossing examenvragen Software Ingenieurstechnieken 12 beperkte, coherente methoden geen te diep geneste uitdrukkingen gebruik geen zelfde variabelen voor doelen goede documentatie volg programmeerrichtlijnen binnen team benamingen indentatie documentatie 11 Geef 15 puntjes over het schrijven van ononderhoudbare code. Marge van 5 extra puntjes toegevoegd :-) 1. Lieg in de commentaar of laat na deze te onderhouden. 2. Maak buitengewoon slechte documentatie, of beter: documenteer gewoon niet. 3. Zorg dat er minstens 25 plaatsen zijn in de code die bijwerking nodig hebben als het programma wordt gewijzigd. Het is per slot van rekening JOUW code en niemand heeft er zaken mee. 4. Geen herbruikbare code produceren, maar telkens knippen en plakken als je iets nodig hebt. 5. Gebruik nooit code formatters. 6. Gebruik nooit { of } rond lussen of selecties en zorg daarbij ook nog voor verkeerde indentatie, je zal zien dat je zelfs de meest geoefende programmeur hiermee in de luren kunt leggen. 7. Vermijd abstractie en inkapseling van code, zodat buitenstaanders de hele methode/- klasse moeten kennen eer ze er gebruik van kunnen maken. 8. Probeer zo veel mogelijk samen te nemen op 1 lijn. Dit spaart verscheidene lijnen typwerk. 9. Negeer de naamgevingsconventies compleet. De compiler geeft toch geen waarschuwingen. 10. Maak nooit een ontwerp, da s enkel voor feilbare mensen. 11. Delen van de code die niet meer nodig zijn, hoor je gewoon achter te laten in het programma. Wie weet zal je ze ooit nog nodig hebben. 12. Gebruik in Java de verschillende manieren om arrays te declareren (String[] x; en String x[];) door elkaar. 13. Maak nooit changelogs van je programma. 14. Gebruik nooit exceptions, die zijn niet nodig in goede code. Of gebruik de algemene exception met een try-catch waar de catch System.exit(); oproept. 15. Gebruik namen voor dezelfde acties en dezelfde namen voor acties. 16. Gebruik een kleine letter l en geen grote om een long aan te duiden: 10l in plaats van 10L 17. Zorg ervoor dat elke methode iets meer of iets minder doet dan wat de naam ervan suggereert. 18. Converteer nooit naar S.I.-eenheden vooraleer door te gaan met berekeningen, maar gebruik alle eenheden compleet willekeurig door elkaar in het programma. 19. Maak zoveel mogelijk variabelen statisch. Als je toch nooit meer dan 1 instantie zult nodig hebben, dan zal dat bij andere mensen allicht ook zo zijn.

13 Oplossing examenvragen Software Ingenieurstechnieken Check nooit of binnenkomende input correct is. 12 Bespreek whitebox- en blackbox-tests en de integratie Blackbox tests Wat? aantonen dat: functies werken inputs goed geaccepteerd worden outputs goed geproduceerd worden integriteit van externe info bewaard blijft niet kijken hoe systeem er van binnen uitziet, meer gericht op de informatie vooral na whitebox testing Hoe? 1 geldige en 2 ongeldige inputs proberen grenzen inputdomein uittesten vergelijkingstests: programma s door verschillende groepen geïmplementeerd uittesten op: op informatie op performantie (vooral voor kritische toepassingen) 12.2 Whitebox tests Wat? Gebruikt controlestructuur van ontwerp/code om de tests te ontwerpen: alle mogelijke paden doorlopen alle logische beslissingen bekijken alle lussen uitvoeren op grenzen en erbinnen datastructuren bekijken Waarom niet enkel blackbox? logische fouten en verkeerde veronderstellingen zijn omgekeerd evenredig met de kans dat een pad wordt uitgevoerd pad kan regelmatig gevolgd worden, terwijl gedacht wordt dat dit weinig gebeurt typfouten geven evenveel kans op een obscuur als op een hoofdpad Hoe? Basispadtests: garanderen dat elk pad minstens eenmalig wordt uitgevoerd flowgraph: sequentie, if, while, case, until

14 Oplossing examenvragen Software Ingenieurstechnieken 14 elke cirkel vertegenwoordigt 1 of meer niet vertakkende uitdrukkingen complexiteit programma bevat aantal onafhankelijke paden testdata uit afleiden Testen van condities en mogelijke fouten boolean operator error boolean variable error boolean parenthesis error relational operator error arithmetic expression error Dataflowtests: bekijken van definities van variabelen gebruik (inhoud) van variabelen Lustests Enkelvoudige lus (n=max): overslaan 1 en 2 keer doorlopen m keer doorlopen n-1, n+1, n keer doorlopen Geneste lus: alle mogelijke combinaties niet te doen 1 lus tegelijk beginnen met binnenste anderen op minimum Geconcateneerde lus: indien afhankelijk van elkaar: testen zoals geneste indien onafhankelijk van elkaar: testen zoals enkelvoudige Ongestructureerde lus: herontwerpen! 12.3 Integratietests Bottom up: eerst laagste units, dan die die er gebruik van maken Top down: eerst controlling objects, met speciale progs voor vaste antwoorden en andere componenten Big bang: na unit testing alles in 1 keer samenvoegen (moeilijk om fouten te vinden) Sandwich: als systeem in 3 lagen top-down en dan bottom up 13 Bespreek kort Unified Process en Extreme Programming Unified Process Use Case driven

15 Oplossing examenvragen Software Ingenieurstechnieken 15 Figuur 2: Het Unified Process is Use Case driven de use cases vloeien voort uit het ontwerp de use cases hebben een weerslag op de analyse en de analyse verfijnt de use cases de use cases komen tot uiting in het ontwerp: alle modellen moeten conform de use cases zijn implementatie moet conform de use cases zijn testen met use cases in het achterhoofd Architecture centric architectuur = opbouw van systeem, info over de onderdelen en relaties onderling logisch opdelen in subsystemen waartussen de afhankelijkheden eenvoudig + beperkt zijn groeit uit de noden weergegeven in use cases Beïnvloed door: platform waar het op moet draaien: OS, DBMS, netwerkprotocollen,... herbruikbare delen: GUI,... niet-functionele eisen: performantie, betrouwbaarheid,... architectuur en use cases worden samen met elkaar volwassen gedurende de ontwikkeling tot een stabiel systeem Iteratief en incrementeel Zie ook 1.3 op pagina 3. Iteratief iteratie = aanpakken van een groep use cases die samen het product - zoals het dan is - uitbreiden. behandeling belangrijkste risico s eerste iteraties behandelen grootste risico s, niet uitstellen! vroege prototypes mogen prototypes zijn die worden weggegooid. mini-project vanaf use case: 1. analyse 2. ontwerp

16 Oplossing examenvragen Software Ingenieurstechnieken 16 Increment 3. implementatie 4. test toevoeging extra functionaliteit ook aan model, document niet noodzakelijk additief, ook vervanging mogelijk 13.2 Rational Unified Process (te kennen?) Levenscyclus bestaat uit aantal cycli. Bij elke cyclus wordt een nieuwe release geproduceerd. 1. inception: aanvang 2. elaboration: uitvoerige behandeling 3. construction: bouwen 4. transition: overgang Elke fase bestaat uit een aantal iteraties en wordt beëindigd met een goed gedefiniëerde mijlpaal Agile Programming Niet te kennen, maar verduidelijkend bij Extreme Programming prioriteit: klanttevredenheid wijziging eisen altijd welkom elke paar weken werkende software ontwikkelen klanten en ontwikkelaars werken dagelijks samen in dit model neem gemotiveerde mensen, ondersteun ze en vertrouw ze face-to-face communicatie meten van vooruitgang door werkende software aandacht voor technische uitmuntendheid en goed ontwerp eenvoud is essentieel zelforganiserende teams zijn volgens dit model het best regelmatige reflectie van team om efficiënter te werken kenmerken: chaordic: chaos + orde nadruk op samenwerken nét genoeg methodologie Extreme Programming iedereen ontwerpt elke dag altijd eenvoudigste kiezen code steeds herzien altijd testen ontwerp en verfijn steeds de architectuur nieuwe code elke dag integreren en testen elke dag afleveren klant/gebruiker moet elke dag beschikbaar zijn voor vragen/evaluatie

17 Oplossing examenvragen Software Ingenieurstechnieken 17 code van iedereen iedereen mag wijzigen elke dag halfuurtje samen het werk verdelen optimale projectlengte: 6 à 9 maanden nadelen: maximaal 3 weken vooruit plannen moeilijk om totale kostprijs op voorhand in te schatten werken aan kleine blokjes en integreren in groot geheel wat is structuur van groot geheel? gebruiker/klant niet altijd beschikbaar Volgens Computer artikel 2004: vaak meer talent in problemen oplossen dan in samenwerken vaak problemen laten sudderen tot plots inzicht, maar daar is geen tijd voor (met 2 aan 1 computer) iedereen in gemeenschappelijke ruimte lawaai minder concentratie om onderzoeksartikelen te lezen degenen die het goed kunnen uitleggen (babbelen) dit model vaker op de voorgrond dan degenen die echt de kunde hebben om de klus te klaren 14 Hoe ga je de kwaliteit van software beoordelen? Bespreek ook kort Capability Maturity Model en ISO Hoe kwaliteit te beoordelen? Correctness (correctheid): formele 1:1-overeenkomst tussen software en functionele specificatie niet mogelijk om correctheid te bewijzen in complexe producten als software functionele specs zelden precies en stabiel genoeg Reliability (betrouwbaarheid): gedraagt zich goed en zoals de gebruiker verwacht (wil niet zeggen dat deze geen fouten kan bevatten) Robustness (robuustheid): niet crashen of onherstelbaar falen Performance (performantie): vooropgestelde doelen: meestal response time nogal zwart-witte kijk op kwaliteit Usability (bruikbaarheid): user friendliness: hoe makkelijk kunnen de gebruikers de software voor hen doen werken? subjectief vooral UI-ontwerp hoe meer standaard, hoe meer bruikbaar Understandability (verstaanbaarheid): interne structuur en gedrag voorwaarde voor onderhoudbaarheid Maintainability (onderhoudbaarheid): corrigeren van fouten en onvolmaaktheden aanpassen aan nieuwe eisen verbeteren om nieuwe kwaliteiten te geven

18 Oplossing examenvragen Software Ingenieurstechnieken 18 Scalability (schaalbaarheid): gemak waarmee software grote schaal kan volgen enkel als duidelijke, verstaanbare architectuur Understandability + Maintainability + Scalability = Supportability Reusability (herbruikbaarheid): slaat zowel op het product als op het gebruikte ontwikkelproces software als component in een ander product software als generisch framework dat aan nieuw product moet aangepast worden Portability (overdraagbaarheid): verschillende hard- en/of software-platformen zonder of met kleine aanpassingen interoperability: samenleven/samenwerken met andere software (die mogelijks nog niet bestaat) open systemen Productivity (productiviteit): proceskwaliteit: efficiëntie en performantie van proces snelheid waarmee software geproduceerd wordt, gegeven een aantal resources Timeliness: proceskwaliteit mogelijkheid op tijd software te leveren volgens oorspronkelijk plan on-time-to-market (commerciële software) Visibility (zichtbaarheid): proceskwaliteit transparant proces: duidelijk gedefiniëerd en gedocumenteerd vereiste voor CMM en ISO ISO 9000 voor alle industriën ISO 9001 is meest algemeen: ontwerp, ontwikkeling en onderhoud van producten ISO past ISO 9001 toe op software-ontwikkeling niet specifiek gericht op software, maar op algemene principes die kunnen worden toegepast bedrijf moet: standaarden en procedures definiëren gedocumenteerd in organisatorische kwaliteitshandboek proces definiëren met beschrijving van nodige documenten om aan te tonen dat procedures gevolgd zijn gedurende productontwikkeling ISO 9000 legt geen kwaliteitsproces vast certificatie na externe audit door erkende Registrar niet noodzakelijk betere software geen aandacht voor: zorgen dat processen best practices reflecteren productkwaliteit

19 Oplossing examenvragen Software Ingenieurstechnieken 19 mogelijk om bvb. testproces te definiren dat leidt tot slechte software: zolang proces gedocumenteerd en gevolgd conform de standaard 8 principes van versie 2000 klanten: focus op noden, eisen en verwachtingen van klanten leiderschap: geen eenduidige richting aan en motiveer mensen betrokkenheid: betrek mensen op alle niveau s en zorg dat ze zich kunnen ontplooien gebruik processen systeembenadering: behandel gerelateerde processen als 1 systeem continue verbetering beslissingen nemen op basis van feiten werk met leveranciers: onderhoud win-win-relatie 14.3 Capability Maturity Model (CMM) Rol van CMM levert mogelijkheid om de softwarecapaciteit van een onderneming te meten zet doelen en prioriteiten voor procesverbetering helpt acties te plannen geeft een procesmanagement en kwaliteitsverbeteringsconcepten toe te passen op softwareontwikkeling en -onderhoud leidt een organisatie naar software engineering excellence Mature vs. immature process Immature process ad hoc: geïmproviseerd niet nauwgezet gevolgd/afgedwongen zwaar afhankelijk van huidige ontwikkelaars moeilijk om productkwaliteit te voorspellen minder goede schattingen grote kans op kost- en planningsproblemen halen van planning vaak ten koste van functionaliteit en kwaliteit gebruiken nieuwe technologie is heir zeer risicovol Mature process gedefinieerd + goed gedocumenteerd ondersteund door management rollen en verantwoordelijkheden goed afgelijnd trouwheid aan proces nagekeken en afgedwongen consistent werken gemeten ondersteuning door technologie

20 Oplossing examenvragen Software Ingenieurstechnieken Hoe bereiken? Trapsgewijs: 1. Initieel: processen ad hoc en chaotisch 2. Herhaalbaar: er is een basisprojectmanagementproces voor volgen van cost planning en functionaliteit 5. er is procesdiscipline om vroegere successen te herhalen 6. Gedefinieerd: proces voor management en engineering is gestandaardiseerd, gedocumenteerd en geïntegreerd op schaal van de hele organisatie 7. Gemanaged: softwareproces en -kwaliteit worden gedetailleerd gemeten en gecontroleerd 8. Optimaliserend: continuë procesverbetering door kwantitatieve feedback van proces en door testen van nieuwe ideen en technologieën Testing maturity model fase 0: geen verschil tussen testen en debuggen fase 1: doel van testen is tonen dat software werkt fase 2: doel van testen is tonen dat software niet werkt fouten te vermijden in de toekomst fase 3: doel van testen is niet om iets te bewijzen risico op fouten reduceren tot aanvaardbaar niveau fase 4: doel van testen is fouten vermijden in de toekomst Nota: het is makkelijker om ISO 9000-compliant te worden als je al conform CMM bent, dan omgekeerd. 15 Wat is software configuration management? = Manier om een veranderend software-ontwikkelingsproject te controleren en te managen. Problemen: hoe versioneren van wijzigingen indien met meerdere personen werken? tijdsdruk: simultaan meerdere wijzigingen aan software grote groepen ontwikkelaars overal ter wereld verspreid Oplossing 3-delig: Identificatie: naam + versienummer elke versie kan onafhankelijk gebruikt, getest of verkocht worden elke wijziging identificeren en versioneren alles in 1 repository: soms kopieën in geografisch verspreide sites periodische synchronisatie Communicatie: informatie over taken

21 Oplossing examenvragen Software Ingenieurstechnieken 21 nog te doen mee bezig afgehandeld wie doet wat? Kostcontrole: elke wijziging aanvragen en laten goedkeuren prioriteiten stellen op elk ogenblik zicht op staat van het project 16 Bespreek kort de Factory Method, Abstract Factory en Singleton patronen Dependency Inversion Principle (DIP) niet te kennen maar belangrijke info Hogere modules mogen niet afhankelijk zijn van lagere modules, maar op abstracties Abstracties mogen niet afhankelijk zijn van details, maar details op abstracties Scheiden van de lagen en onafhankelijk wijzigen Interfaces voorzien tussen de subsystemen Simple Factory Wat is Factory? Details voor objectcreatie van hogere module (client) verschuiven naar lagere module (server). Voorbeeld: PizzaStore. Listing 1: Hoeveel types pizza zijn er? Zijn er aanpassingen nodig? 1 public Pizza o rderpizza ( ) { 2 p i z z a. prepare ( ) ; 3 p i z z a. bake ( ) ; 4 p i z z a. cut ( ) ; 5 p i z z a. box ( ) ; 6 return p i z z a ; 7 Pizza p i z z a = new Pizza ( ) ; 8 } Listing 2: PizzaStore: eerste aanpassing 1 public Pizza o rderpizza ( S t r i n g type ) { 2 Pizza p i z z a ; 3 i f ( type. e q u a l s ( c h e e s e ) ) 4 p i z z a = new CheesePizza ( ) ; 5 else i f ( type. e q u a l s ( g r e e k ) ) 6 p i z z a = new GreekPizza ( ) ; p i z z a. prepare ( ) ;

22 Oplossing examenvragen Software Ingenieurstechnieken 22 9 p i z z a. bake ( ) ; 10 p i z z a. cut ( ) ; 11 p i z z a. box ( ) ; return p i z z a ; 14 } De methode orderpizza zal sterk wijzigen bij veranderingen en kunnen we dus best afzonderen, de andere code blijft min of meer dezelfde. In listing 3 isoleren we de code en wordt deze dus bruikbaar vanuit andere objecten. Listing 3: PizzaStore: factory toevoegen 1 public class SimplePizzaFactory { 2 public Pizza c r e a t e P i z z a ( S t r i n g type ) { 3 Pizza p i z z a = null ; 4 5 i f ( type. e q u a l s ( cheese ) ) { 6 p i z z a = new CheesePizza ( ) ; 7 } else i f ( type. e q u a l s ( pepperoni ) ) { 8 p i z z a = new PepperoniPizza ( ) ; 9 } else i f ( type. e q u a l s ( clam ) ) { 10 p i z z a = new ClamPizza ( ) ; 11 } else i f ( type. e q u a l s ( v e g g i e ) ) { 12 p i z z a = new VeggiePizza ( ) ; 13 } return p i z z a ; 16 } 17 } public class PizzaStore { 20 SimplePizzaFactory f a c t o r y ; public P izzastore ( SimplePizzaFactory f a c t o r y ) { 23 this. f a c t o r y = f a c t o r y ; 24 } 25 public Pizza orderpizza ( S t r i n g type ) { 26 / Dynamic b i n d i n g : d i t o b j e c t van k l a s s e P i z z a S t o r e 27 weet n i e t welk type Pizza het t e r u g z a l k r i j g e n. / 28 Pizza p i z z a = f a c t o r y. c r e a t e P i z z a ( type ) ; p i z z a. prepare ( ) ; 31 p i z z a. bake ( ) ; 32 p i z z a. cut ( ) ; 33 p i z z a. box ( ) ; return p i z z a ;

23 Oplossing examenvragen Software Ingenieurstechnieken } 37 } Dus voordelen van Simple Factory: Creatie van objecten verschuiven naar een object Wijzigen op 1 plaats Herbruikbaar 16.3 Factory Method Stel dat er niet alleen verschillende smaken maar ook verschillende types pizza zijn. Dan is de aangewezen werkwijze absoluut niet dit: Listing 4: Hoe het NIET moet 1 i f ( s t y l e == New Y o r k ) { 2 i f ( type == c h e e s e ) 3 return new NewYorkCheesePizza ( ) ; 4 else i f (... ) } 7 else i f ( s t y l e == C h i c a g o ) { 8 i f ( type == c h e e s e ) 9 return new ChicagoCheesePizza ( ) ; 10 else i f (... ) maar het gebruik van polymorfe factories: Listing 5: Gebruik van polymorfe factories 1 public abstract class PizzaStore { 2 3 protected abstract Pizza c r e a t e P i z z a ( S t r i n g type ) ; 4 5 public Pizza orderpizza ( S t r i n g type ) { 6 Pizza p i z z a = c r e a t e P i z z a ( type ) ; 7 p i z z a. prepare ( ) ; 8 p i z z a. bake ( ) ; 9 p i z z a. cut ( ) ; 10 p i z z a. box ( ) ; 11 return p i z z a ; 12 } 13 } public class NYPizzaStore extends PizzaStore { 16 Pizza c r e a t e P i z z a ( S t r i n g item ) { 17

24 Oplossing examenvragen Software Ingenieurstechnieken i f ( item. e q u a l s ( cheese ) ) { 19 return new NYStyleCheesePizza ( ) ; 20 } else i f ( item. e q u a l s ( v e g g i e ) ) { 21 return new NYStyleVeggiePizza ( ) ; 22 } else i f ( item. e q u a l s ( clam ) ) { 23 return new NYStyleClamPizza ( ) ; 24 } else i f ( item. e q u a l s ( pepperoni ) ) { 25 return new NYStylePepperoniPizza ( ) ; 26 } else 27 return null ; } 30 } Doel: creatie van objecten overhevelen naar subklassen van de factory Context: DIP: abstractie en geen concrete details! Oplossing: definieer een interface (abstracte klasse PizzaStore) voor de creatie van een familie objecten, maar laat de subklassen beslissen welk type object ze aanmaken Abstract Factory Voorbeelden Door mij (onder voorbehoud van fouten dus) uitgewerkt pizzavoorbeeld uit cursus. Listing 6: Abstract Pizza Factory 1 / A l l e methoden z i j n in in een i n t e r f a c e per d e f i n i t i e 2 a b s t r a c t en dus i s g e b r u i k van keyword a b s t r a c t 3 n i e t v e r e i s t / 4 public interface I n g r e d i e n t F a c t o r y 5 { 6 protected void createdough ( ) ; 7 protected void createsauce ( ) ; 8 protected void createcheese ( ) ; 9 protected void c r e a t e V e g g i e s ( ) ; 10 } public class NewYorkPizzaIngredientFactory 13 implements I n g r e d i e n t F a c t o r y 14 { 15 private int dough =... ; 16 private int sauce =... ; 17 private int v e g g i e s =... ; 18 private int cheese =... ; 19 public NewYorkPizzaIngredientFactory ( ) 20 { 21...

25 Oplossing examenvragen Software Ingenieurstechnieken } 23 protected int createdough ( ) 24 { 25 return this. dough ; 26 } 27 protected int createsauce ( ) 28 { 29 return this. sauce ; 30 } 31 protected int createcheese ( ) 32 { 33 return this. cheese ; 34 } 35 protected int c r e a t e V e g g i e s ( ) 36 { 37 return this. v e g g i e s ; 38 } } public abstract class Pizza 43 { 44 protected S t r i n g name = null ; 45 protected int dough = 0 ; 46 protected int cheese = 0 ; 47 protected int v e g g i e s = 0 ; 48 protected int sauce = 0 ; 49 protected I n g r e d i e n t F a c t o r y f a c t o r y = null ; 50 / Onderstel dat e n k e l de b e r e i d i n g e n 51 van de p i z z a s v e r s c h i l l e n. De manier van snijden, bakken 52 en van inpakken n i e t. / 53 public abstract void prepare ( ) ; 54 public void setname ( S t r i n g n ) 55 { 56 this. name = n ; 57 } 58 public void cut ( int p i e c e s ) 59 { } 62 public void box ( ) 63 { } 66 public void bake ( ) 67 { 68...

26 Oplossing examenvragen Software Ingenieurstechnieken } 70 } / z e l f d e voor andere smaken p i z z a / 73 public class CheesePizza extends Pizza 74 { 75 public CheesePizza ( I n g r e d i e n t F a c t o r y f a c t o r y ) 76 { } 79 private void prepare ( ) 80 { 81 this. dough = f a c t o r y. createdough ( ) ; 82 this. sauce = f a c t o r y. createsauce ( ) ; 83 this. v e g g i e s = f a c t o r y. c r e a t e V e g g i e s ( ) ; 84 this. c heese = f a c t o r y. createcheese ( ) ; 85 } } public abstract class PizzaStore 91 { 92 private I n g r e d i e n t F a c t o r y f a c t o r y = null ; 93 protected abstract Pizza c r e a t e P i z z a ( S t r i n g item ) ; 94 } / z e l f d e voor andere soorten w i n k e l s / 97 public class NYPizzaStore extends PizzaStore 98 { 99 public NYPizzaStore ( ) 100 { 101 this. f a c t o r y = new NewYorkPizzaIngredientFactory ( ) ; 102 } 103 protected Pizza c r e a t e P i z z a ( S t r i n g item ) { 104 Pizza p i z z a = null ; 105 i f ( item. e q u a l s ( cheese ) ) { 106 p i z z a = new CheesePizza ( f a c t o r y ) ; 107 p i z z a. setname ( New York S t y l e Cheese Pizza ) ; 108 } else i f ( item. e q u a l s ( v e g g i e ) ) { 109 p i z z a = new VeggiePizza ( f a c t o r y ) ; 110 p i z z a. setname ( New York S t y l e Veggie Pizza ) ; 111 } else i f ( item. e q u a l s ( clam ) ) { 112 p i z z a = new ClamPizza ( f a c t o r y ) ; 113 p i z z a. setname ( New York S t y l e Clam Pizza ) ; 114 } 115 p i z z a. prepare ( f a c t o r y ) ;

27 Oplossing examenvragen Software Ingenieurstechnieken p i z z a. bake ( ) ; 117 p i z z a. cut ( ) ; 118 p i z z a. box ( ) ; 119 return p i z z a ; 120 } } Wat gebeurt er precies? Figuur 3 verduidelijkt wat er gebeurt in het pizzavoorbeeld. Ik heb het niet zelf gemaakt, wat een garantie is voor de juistheid: het is afkomstig van de slides van Chuck Allison, waar mevr. Vorstermans de voorbeelden vandaan haalde Opmerkingen De stappen die telkens gezet werden om het voorbeeld te verfijnen zijn de volgende: 1. Simple Factory: code bijeenbrengen (nieuwe klasse of statische methode) voor herbruikbaarheid 2. Factory Method: zelfde als Simple Factory, maar het aantal verschillende objecten dat kan worden aangemaakt is groter en dus is opsplitsen vereist meer dan 1 factory (overerving/interfaces), factories geven 1 object terug. 3. Abstract Factory: maakt een reeks van objecten aan. De reden van de polymorfe invulling is wederom dezelfde als in Factory Method: het bestaan van verschillende mogelijkheden. Het is de bedoeling dat alle objecten van de reeks nodig zijn. De factory wordt door de PizzaStore doorgegeven aan de Pizza, zodat die er zijn plan mee kan trekken. Meer info zie figuur 3. Figuur 3: createpizza geeft de correcte ingredientfactory door aan CheesePizza via de prepare(factory)-methode

28 Oplossing examenvragen Software Ingenieurstechnieken Verschil tussen Abstract Factory en Factory Method Factory Method maakt 1 object kan teruggebracht worden tot een statische methode abstracte interface heeft vaak methode die factory-methode aanroept Abstract Factory 1. maakt familie gerelateerde objecten 2. meerdere polymorfe methodes nodig 3. clients gebruiken factory-object 16.6 Singleton verplichten van maximum 1 instantie van een object (logging, printserver, cache,...) statische methode om object terug te geven nog niet gecreëerd? creëer het! referentie teruggeven geen publieke constructor verbiedt kopiëren, klonen en toewijzen synchronized om gelijktijdig gebruik (en dus eventueel aanmaak van een kopie) te verhinderen 1 public class S i n g l e t o n Listing 7: Voorbeeld van Singleton Pattern Code 2 { private static S i n g l e t o n i n s t a n t i e = null ; 3 private S i n g l e t o n (){} 4 public synchronized static S i n g l e t o n g e t I n s t a n t i e ( ) 5 { i f ( i n s t a n t i e == null ) i n s t a n t i e = new S i n g l e t o n ( ) ; 6 return i n s t a n t i e ; 7 } 8 } 17 Bespreek kort de Strategy, Observer en Chain of Responsibility patronen Strategy-patroon Soms is het nodig om gedragingen volledig van elkaar te splitsen, zodat we een grotere flexibiliteit hebben in de implementatie: we hebben niet altijd alle gedragingen nodig sommige gedragingen zijn gelijkaardig, maar verschillen toch van elkaar compositie (opnemen van objecten in een object) in plaats van overerving Het veranderlijke scheiden van wat hetzelfde blijft Het voorbeeld met de eendensimulatie illustreert dit:

29 Oplossing examenvragen Software Ingenieurstechnieken 29 Figuur 4: Eendjes: Illustratie van het Strategypatroon Voordelen: Behaviors toevoegen zonder Duck te veranderen Goed herbruikbaar Gedragingen veranderen at runtime (setflybehavior(flybehavior fb)) 17.2 Observer-patroon of Publisher/Subscriber-patroon Te gebruiken als data op 1 plaats wijzigt en andere componenten zijn daarvan afhankelijk. publisher houdt lijst van geregistreerde subcribers bij subscriber registreren en de-registreren bij publisher wijziging publisher stuurt verwittiging naar subscribers; subscribers halen zelf gewijzigde data op Voordeel: geen te sterke koppeling van subscriber en publisher 17.3 Chain of Responsibility-patroon Deze beschrijft een hele keten van objecten die doorlopen wordt als een bepaalde gebeurtenis zich voorgedaan heeft. Een voorbeeld daarvan is een systeem dat zorgt voor logging: 1 import java. u t i l. ; 2 Listing 8: Chain of Responsibility: Logger

30 Oplossing examenvragen Software Ingenieurstechnieken 30 3 public abstract c l a s s Logger { 4 public static int ERR = 3 ; 5 public static int NOTICE = 5 ; 6 public static int DEBUG = 7 ; 7 protected int mask ; 8 // the next element in the chain o f r e s p o n s i b i l i t y 9 protected Logger next ; 10 public Logger setnext ( Logger l ) 11 { next = l ; return this ; } 12 abstract public void message ( S t r i n g msg, int p r i o r i t y ) ; 13 } public c l a s s DebugLogger extends Logger { 16 public DebugLogger ( int mask ) 17 { this. mask = mask ; } 18 public void message ( S t r i n g msg, int p r i o r i t y ) { 19 i f ( p r i o r i t y <= mask ) 20 System. out. p r i n t l n ( Writing to debug output : +msg ) ; 21 i f ( next!= null ) 22 next. message (msg, p r i o r i t y ) ; 23 } 24 } public c l a s s Logger extends Logger { 27 public Logger ( int mask ) { this. mask = mask ; } public void message ( S t r i n g msg, int p r i o r i t y ) { 30 i f ( p r i o r i t y <= mask ) 31 System. out. p r i n t l n ( Sending via e mail : +msg ) ; 32 i f ( next!= null ) 33 next. message (msg, p r i o r i t y ) ; 34 } 35 } public class StderrLogger extends Logger { 38 public StderrLogger ( int mask ) 39 { this. mask = mask ; } public void message ( S t r i n g msg, int p r i o r i t y ) { 42 i f ( p r i o r i t y <= mask ) 43 System. out. p r i n t l n ( Writing to s t d e r r : +msg ) ; 44 i f ( next!= null ) 45 next. message (msg, p r i o r i t y ) ; 46 } 47 } public class ChainOfResponsibilityExample {

31 Oplossing examenvragen Software Ingenieurstechnieken public static void main ( S t r i n g [ ] args ) { 51 // b u i l d i n g the chain o f r e s p o n s i b i l i t y 52 Logger l = new DebugLogger ( Logger.DEBUG) ; 53 Logger e = new Logger ( Logger. NOTICE) ; 54 Logger s = new StderrLogger ( Logger.ERR) ; 55 l. setnext ( e ) ; 56 e. setnext ( s ) ; 57 // handled by DebugLogger 58 l. message ( Entering f u n c t i o n y., Logger.DEBUG) ; 59 // handled by Debug and StderrLogger 60 l. message ( Step1 completed., Logger.NOTICE) ; 61 // handled by a l l t h r e e Logger 62 l. message ( An e r r o r has occurred., Logger.ERR) ; 63 } 64 } Dit wordt de output: Writing to debug output: Entering function y. Writing to debug output: Step1 completed. Sending via Step1 completed. Writing to debug output: An error has occurred. Sending via An error has occurred. Writing to stderr: An error has occurred. 18 Bespreek kort de Adapter, Facade en Decorator patronen Adapter-patroon Probleem: nodig als een toepassing reeds een bepaalde API/library/interface gebruikt, maar deze na verloop van tijd verandert, dan kan dit problemen opleveren. Oplossing: schrijf een adapter/wrapper klasse die de conversie maakt tussen de nieuwe API/interface/library en jouw eigen programma. voorbeeld: zie diagram op figuur 5 op de volgende pagina In listing 9 op de pagina hierna zien we hoe we ons voorbeeld met de eendensimulatie zouden veranderen indien we een kalkoen zouden toevoegen: 1. kalkoenen schrokken en kwaken (?) niet 2. kalkoenen vliegen kortere afstanden

32 Oplossing examenvragen Software Ingenieurstechnieken 32 Figuur 5: Algemeen diagram van het adapterpatroon Listing 9: Adapter: toevoegen voor een kalkoen aan de eendjessimulatie 1 public c l a s s TurkeyAdapter implements Duck { 2 Turkey turkey ; 3 public TurkeyAdapter ( Turkey turkey ) { 4 this. turkey = turkey ; 5 } 6 public void quack ( ) { 7 turkey. gobble ( ) ; 8 } 9 public void f l y ( ) { 10 for ( int i =0; i < 5 ; i++) { 11 turkey. f l y ( ) ; 12 } 13 } 14 } 15 public class AdapterTest 16 { 17 public static void main ( S t r i n g [ ] args ) 18 { 19 Duck d = new Duck ( Donald ) ; 20 Turkey t = new Turkey ( Geraar ) ; 21 TurkeyAdapter t a = new TurkeyAdapter ( t ) ; 22 ta. quack ( ) ; 23 ta. f l y ( ) ; 24 } 25 }

33 Oplossing examenvragen Software Ingenieurstechnieken Two-way Adapter Dit is een adapter-klasse die kan dienen als wrapper voor beide klassen: dus een eend converteren naar een kalkoen n omgekeerd: meervoudige overerving (C++) of interfaces (Java) in het geval van de eendensimulatie zou een voorbeeld zijn: een wrapperklasse die de methodes makesound() en fly() implementeert 18.2 Facade-patroon dient om verschillende verzamelingen klassen - die niet ontworpen zijn om met elkaar samen te werken - toch te laten samenwerken voorbeelden: universele afstandsbediening, compiler (voor computerarchitecturen),... complexiteit reduceren door verdeling in lagen faade voor elke laag 18.3 Verschil tussen faade en adapter: adapter converteert faade vereenvoudigt 18.4 Decorator-patroon Gebruikt om extra features toe te voegen aan 1 enkel object en niet aan de hele klasse waaruit het object geïnstantieerd is. Moeilijk met overerving omdat men dan een gigantisch aantal verschillende klassen krijgt (2 n klassen voor n eigenschappen). Indien we dit doen volgens het decorator-patroon, dan laten we de decorator (in feite dus een wrapper-klasse) het object omvatten dat extra functionaliteit moet krijgen. typisch wordt het te decoreren object doorgegeven als argument in de constructor van het decorator-object dit laat toe om at runtime gedragingen toe te voegen decorator handelt alle oproepen naar het gedecoreerd object, af en voegt er eventueel extra functionaliteit aan toe. decorator heeft dus een identische interface, met extra uitbreidingen decorator is flexibeler gebruik van decorators zorgt ervoor dat de gedecoreerde objecten licht blijven (geen overhead). Eventueel kan men een abstracte decorator gebruiken indien veel verantwoordelijkheden moeten worden toegevoegd voorbeelden: Java I/O klassen, toegangscontrole tot objectfunctionaliteit,

34 Oplossing examenvragen Software Ingenieurstechnieken 34 Figuur 6: Schema van het verloop bij service engineering 19 Bespreek kort de Service Oriented Architecture. Basis: service Architectuur: loosely coupled, onafhankelijke services Toegang tot service: platform-onafhankelijk is eigenlijk een verdere evolutie van scheiden van het werk want herbruikbaarheid van services is groter dan die van objecten services kunnen plaatselijk voorzien worden of extern uitbesteed worden systemen interageren met elkaar in XML integratie van applicaties in technologieën evolutie: 1. 1ste generatie: fat clients aanroepen service leveranciers rechtstreeks plaats voor business logica? 2. 2de generatie: introductie middle tiers voor abstractie scheiding tussen providers en consumers (analoog met introductie middleware tussen client en back-end servers) Middle Tier Services: 1. Validation service: controleren van data gezonden door aanvrager 2. Transformation service: omzetten van data naar ander formaat (bv via XSLT) 3. Enrichment service: bvb. extra data toevoegen 4. Mediation service: meestal gewoon doorgeven, soms met validatie, toevoegen of transformaties 5. Orchestration Services: groepering van meerdere application services indien nodig 6. Workflow Services: bevatten menselijke interacties Geïmplementeerd bovenop HTTP/HTTPS-laag goede omgang met firewalls 19.1 Services Een service wordt gedefinieerd als: A loosely-coupled, reusable software component that encapsulates discrete functionality which may be distributed and programmatically accessed. A