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

Oplossing examenvragen Software Ingenieurstechnieken

1

1

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

1.1

Software Engineering

Software Engineering 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. 1.2.1 Watervalmodel Een lineaire opvatting van software development. Dit houdt in dat de software 5 fasen doorloopt: 1. 2. 3. 4. 5.

Analyse: onderzoek en overleg over de vereisten en specificaties voor de software Ontwerp: Gedetailleerde uitwerking van de structuur en de werking van de toekomstige software (cfr. UML) Implementatie: het eigenlijke programmeerwerk Test: de software dient uitvoerig aan tests te worden onderworpen voorafgaand aan de integratie en in gebruikname Onderhoud: al het werk dat wordt verricht na het in productie nemen van het eindproduct

Figuur 1: Een illustratie van het watervalmodel

Faysal Boukayoua

3ELICTI (2006-2007)


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)

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

Faysal Boukayoua

3ELICTI (2006-2007)


•

3

prototype hoort snel overzicht te bieden: te veel moeite aan prototype kan een bron van gelden 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

1.3.1 Spiraalmodel Dit is eigenlijk eerder een metamodel: het kan alle andere modellen bevatten Het spiraalmodel bestaat erin dat volgende stappen telkens herhaald worden: 1. 2. 3. 4.

planning risico-analyse (resultaat is altijd: go/no go) engineering: software-ontwikkeling 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

Faysal Boukayoua

3ELICTI (2006-2007)


4

2.1.1 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

2.1.2 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

2.1.3 Over mislukking en succes Top 3 redenen success 1. 2. 3.

betrokkenheid gebruikers steun van management duidelijke eisen en specs

Top 3 redenen challenged 1. 2. 3.

te weinig betrokkenheid gebruikers vage eisen en specs wijzigende eisen en specs

Top 3 redenen impaired 1. 2. 3.

vage eisen en specs te weinig betrokkenheid gebruikers 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%

Faysal Boukayoua

3ELICTI (2006-2007)


2.2

5

Case study

2.2.1 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

2.2.2 Success Hyatt Hotels • • • •

steun van management duidelijke eisen goede planning kleine mijlpalen

Banco Itamarati • • •

goede planning competent personeel steun van management

2.2.3 Top 5 factoren voor succes volgens case study Onderzochte bedrijven mochten punten geven aan factoren die ze belangrijk achtten. 1. 2. 3. 4. 5.

betrokkenheid gebruikers steun van management duidelijke eisen goede planning 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

Faysal Boukayoua

3ELICTI (2006-2007)


•

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

Faysal Boukayoua

3ELICTI (2006-2007)


4.3

Goed plan maken en onderhouden

• • •

compleet gedetailleerd toepasselijk

4.4

Nodige middelen verkrijgen

7

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

Leiderschap

• • • •

voor sommigen hard werk plannen, opvolgen, controleren project bron van wijsheid en steun geen dictator, maar teamlid

Faysal Boukayoua

3ELICTI (2006-2007)


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

• • • • •

Faysal Boukayoua

3ELICTI (2006-2007)


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 interactieme∗ thodes ⇒ commando’s! – persoonlijkheid

Faysal Boukayoua

3ELICTI (2006-2007)


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

• • • •

•

•

•

Faysal Boukayoua

3ELICTI (2006-2007)


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 wor– den 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 (D) @ 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 6= namen voor semantisch 6= operaties

Faysal Boukayoua

3ELICTI (2006-2007)


12

• • • • •

beperkte, coherente methoden geen te diep geneste uitdrukkingen gebruik geen zelfde variabelen voor 6= 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. 2. 3.

4. 5. 6.

7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.

Lieg in de commentaar of laat na deze te onderhouden. Maak buitengewoon slechte documentatie, of beter: documenteer gewoon niet. 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. Geen herbruikbare code produceren, maar telkens knippen en plakken als je iets nodig hebt. Gebruik nooit code formatters. 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. Vermijd abstractie en inkapseling van code, zodat buitenstaanders de hele methode/klasse moeten kennen eer ze er gebruik van kunnen maken. Probeer zo veel mogelijk samen te nemen op 1 lijn. Dit spaart verscheidene lijnen typwerk. Negeer de naamgevingsconventies compleet. De compiler geeft toch geen waarschuwingen. Maak nooit een ontwerp, da’s enkel voor feilbare mensen. 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. Gebruik in Java de verschillende manieren om arrays te declareren (String[] x; en String x[];) door elkaar. Maak nooit changelogs van je programma. 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. Gebruik 6= namen voor dezelfde acties en dezelfde namen voor 6= acties. Gebruik een kleine letter l en geen grote om een long aan te duiden: 10l in plaats van 10L Zorg ervoor dat elke methode iets meer of iets minder doet dan wat de naam ervan suggereert. Converteer nooit naar S.I.-eenheden vooraleer door te gaan met berekeningen, maar gebruik alle eenheden compleet willekeurig door elkaar in het programma. 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.

Faysal Boukayoua

3ELICTI (2006-2007)


13

20.

Check nooit of binnenkomende input correct is.

12

Bespreek whitebox- en blackbox-tests en de integratie.

12.1

Blackbox tests

12.1.1 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

12.1.2 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

12.2.1 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

12.2.2 Hoe? Basispadtests: • •

garanderen dat elk pad minstens eenmalig wordt uitgevoerd flowgraph: sequentie, if, while, case, until

Faysal Boukayoua

3ELICTI (2006-2007)


• • •

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.

13.1

Unified Process

•

•

13.1.1 Use Case driven

Faysal Boukayoua

3ELICTI (2006-2007)


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

13.1.2 Architecture centric • • • •

•

architectuur = opbouw van systeem, info over de 6= 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

13.1.3 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

Faysal Boukayoua

3ELICTI (2006-2007)


3. 4.

16

implementatie test

Increment • • •

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. 2. 3. 4.

inception: aanvang elaboration: uitvoerige behandeling construction: bouwen transition: overgang

Elke fase bestaat uit een aantal iteraties en wordt beëindigd met een goed gedefiniëerde mijlpaal. 13.3

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

13.3.1 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

Faysal Boukayoua

3ELICTI (2006-2007)


• • • •

•

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

14.1

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

• • •

•

•

•

Faysal Boukayoua

3ELICTI (2006-2007)


•

• •

• •

•

•

•

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

14.2

ISO 9000

• • •

voor alle industriën ISO 9001 is meest algemeen: ontwerp, ontwikkeling en onderhoud van producten ISO 9000-3 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

•

• •

Faysal Boukayoua

3ELICTI (2006-2007)


19

∗

•

14.3

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 Capability Maturity Model (CMM)

14.3.1 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

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

Faysal Boukayoua

3ELICTI (2006-2007)


20

14.3.3 Hoe bereiken? Trapsgewijs: 1. 2. 3. 4. 5. 6. 7. 8.

Initieel: processen ad hoc en chaotisch Herhaalbaar: er is een basisprojectmanagementproces voor volgen van cost planning en functionaliteit er is procesdiscipline om vroegere successen te herhalen Gedefinieerd: proces voor management en engineering is gestandaardiseerd, gedocumenteerd en ge¨ıntegreerd op schaal van de hele organisatie Gemanaged: softwareproces en -kwaliteit worden gedetailleerd gemeten en gecontroleerd Optimaliserend: continuë procesverbetering door kwantitatieve feedback van proces en door testen van nieuwe ideen en technologieën

14.3.4 Testing maturity model • • •

•

•

fase fase fase – – fase – – fase

0: geen verschil tussen testen en debuggen 1: doel van testen is tonen dat software werkt 2: doel van testen is tonen dat software niet werkt fouten te vermijden in de toekomst 3: doel van testen is niet om iets te bewijzen risico op fouten reduceren tot aanvaardbaar niveau 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 6= geografisch verspreide sites ⇒ periodische synchronisatie Communicatie: informatie over taken

Faysal Boukayoua

3ELICTI (2006-2007)


•

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.

16.1

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 6= subsystemen. 16.2

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 2 3 4 5 6 7 8

public P i z z a o r d e r P i z z a ( ) { pizza . prepare ( ) ; p i z z a . bake ( ) ; pizza . cut ( ) ; p i z z a . box ( ) ; return p i z z a ; P i z z a p i z z a = new P i z z a ( ) ; } Listing 2: PizzaStore: eerste aanpassing

1 2 3 4 5 6 7 8

public P i z z a o r d e r P i z z a ( S t r i n g type ) { Pizza pizza ; i f ( type . e q u a l s ( c h e e s e ) ) p i z z a = new C h e e s e P i z z a ( ) ; e l s e i f ( type . e q u a l s ( g r e e k ) ) p i z z a = new GreekPizza ( ) ; ..... pizza . prepare ( ) ; Faysal Boukayoua

3ELICTI (2006-2007)


22

p i z z a . bake ( ) ; pizza . cut ( ) ; p i z z a . box ( ) ;

9 10 11 12

return p i z z a ;

13 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 2 3

public c l a s s S i m p l e P i z z a F a c t o r y { public P i z z a c r e a t e P i z z a ( S t r i n g type ) { P i z z a p i z z a = null ;

4

i f ( type . e q u a l s ( ” c h e e s e ” ) ) { p i z z a = new C h e e s e P i z z a ( ) ; } e l s e i f ( type . e q u a l s ( ” p e p p e r o n i ” ) ) { p i z z a = new P e p p e r o n i P i z z a ( ) ; } e l s e i f ( type . e q u a l s ( ” clam ” ) ) { p i z z a = new ClamPizza ( ) ; } e l s e i f ( type . e q u a l s ( ” v e g g i e ” ) ) { p i z z a = new V e g g i e P i z z a ( ) ; }

5 6 7 8 9 10 11 12 13 14

return p i z z a ;

15

}

16 17

}

18 19 20

public c l a s s P i z z a S t o r e { SimplePizzaFactory fac tor y ;

21 22 23 24 25 26 27 28

public P i z z a S t o r e ( S i m p l e P i z z a F a c t o r y f a c t o r y ) { this . f a c t o r y = f a c t o r y ; } public P i z z a o r d e r P i z z a ( S t r i n g type ) { /∗ 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 weet n i e t w e l k t y p e P i z z a h e t t e r u g z a l k r i j g e n . ∗/ P i z z a p i z z a = f a c t o r y . c r e a t e P i z z a ( type ) ;

29

pizza . prepare ( ) ; p i z z a . bake ( ) ; pizza . cut ( ) ; p i z z a . box ( ) ;

30 31 32 33 34

return p i z z a ;

35

Faysal Boukayoua

3ELICTI (2006-2007)


}

36 37

23

} 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 2 3 4 5 6 7 8 9 10 11

i f ( s t y l e == New Y o r k ) { i f ( type == c h e e s e ) return new NewYorkCheesePizza ( ) ; else i f ( . . . ) ... } e l s e i f ( s t y l e == C h i c a g o ) { i f ( type == c h e e s e ) return new C h i c a g o C h e e s e P i z z a ( ) ; else i f ( . . . ) ... maar het gebruik van polymorfe factories: Listing 5: Gebruik van polymorfe factories

1

public abstract c l a s s P i z z a S t o r e {

2

protected abstract P i z z a c r e a t e P i z z a ( S t r i n g type ) ;

3 4

public P i z z a o r d e r P i z z a ( S t r i n g type ) { P i z z a p i z z a = c r e a t e P i z z a ( type ) ; pizza . prepare ( ) ; p i z z a . bake ( ) ; pizza . cut ( ) ; p i z z a . box ( ) ; return p i z z a ; }

5 6 7 8 9 10 11 12 13

}

14 15 16

public c l a s s NYPizzaStore extends P i z z a S t o r e { P i z z a c r e a t e P i z z a ( S t r i n g item ) {

17

Faysal Boukayoua

3ELICTI (2006-2007)


24

i f ( item . e q u a l s ( ” c h e e s e ” ) ) { return new NYStyleCheesePizza ( ) ; } e l s e i f ( item . e q u a l s ( ” v e g g i e ” ) ) { return new NYStyleVeggiePizza ( ) ; } e l s e i f ( item . e q u a l s ( ” clam ” ) ) { return new NYStyleClamPizza ( ) ; } e l s e i f ( item . e q u a l s ( ” p e p p e r o n i ” ) ) { return new NYStylePepperoniPizza ( ) ; } else return null ;

18 19 20 21 22 23 24 25 26 27 28

}

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

16.4

Abstract Factory

16.4.1 Voorbeelden Door mij (onder voorbehoud van fouten dus) uitgewerkt pizzavoorbeeld uit cursus. Listing 6: Abstract Pizza Factory 1 2 3 4 5 6 7 8 9 10

/∗ A l l e methoden z i j n i n i n een i n t e r f a c e p e r d e f i n i t i e 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 ” n i e t v e r e i s t ∗/ public i n t e r f a c e I n g r e d i e n t F a c t o r y { protected void createDough ( ) ; protected void c r e a t e S a u c e ( ) ; protected void c r e a t e C h e e s e ( ) ; protected void c r e a t e V e g g i e s ( ) ; }

11 12 13 14 15 16 17 18 19 20 21

public c l a s s N e w Y o r k P i z z a I n g r e d i e n t F a c t o r y implements I n g r e d i e n t F a c t o r y { private int dough = . . . ; private int s a u c e = . . . ; private int v e g g i e s = . . . ; private int c h e e s e = . . . ; public N e w Y o r k P i z z a I n g r e d i e n t F a c t o r y ( ) { ... Faysal Boukayoua

3ELICTI (2006-2007)


25

} protected int createDough ( ) { return t h i s . dough ; } protected int c r e a t e S a u c e ( ) { return t h i s . s a u c e ; } protected int c r e a t e C h e e s e ( ) { return t h i s . c h e e s e ; } protected int c r e a t e V e g g i e s ( ) { return t h i s . v e g g i e s ; }

22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

}

41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68

public abstract c l a s s P i z z a { protected S t r i n g name = null ; protected int dough = 0 ; protected int c h e e s e = 0 ; protected int v e g g i e s = 0 ; protected int s a u c e = 0 ; 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 ; /∗ O n d e r s t e l d a t e n k e l de b e r e i d i n g e n van de p i z z a ’ s v e r s c h i l l e n . De manier van s n i j d e n , bakken en van i n p a k k e n n i e t . ∗/ public abstract void p r e p a r e ( ) ; public void setName ( S t r i n g n ) { t h i s . name = n ; } public void c u t ( int p i e c e s ) { ... } public void box ( ) { ... } public void bake ( ) { ... Faysal Boukayoua

3ELICTI (2006-2007)


}

69 70

26

}

71 72 73 74 75 76 77 78 79 80 81 82 83 84 85

/∗ z e l f d e voor andere smaken p i z z a ∗/ public c l a s s C h e e s e P i z z a extends P i z z a { public C h e e s e P i z z a ( I n g r e d i e n t F a c t o r y f a c t o r y ) { ... } private void p r e p a r e ( ) { t h i s . dough = f a c t o r y . createDough ( ) ; this . sauce = f a c t o r y . createSauce ( ) ; this . veggies = f a c t o r y . createVeggies ( ) ; this . cheese = f a c t o r y . createCheese ( ) ; }

86 87

}

88 89 90 91 92 93 94

public abstract c l a s s P i z z a S t o r e { 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 ; protected abstract P i z z a c r e a t e P i z z a ( S t r i n g item ) ; }

95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115

/∗ z e l f d e voor andere s o o r t e n w i n k e l s ∗/ public c l a s s NYPizzaStore extends P i z z a S t o r e { public NYPizzaStore ( ) { t h i s . f a c t o r y = new N e w Y o r k P i z z a I n g r e d i e n t F a c t o r y ( ) ; } protected P i z z a c r e a t e P i z z a ( S t r i n g item ) { P i z z a p i z z a = null ; i f ( item . e q u a l s ( ” c h e e s e ” ) ) { p i z z a = new C h e e s e P i z z a ( f a c t o r y ) ; p i z z a . setName ( ”New York S t y l e Cheese P i z z a ” ) ; } e l s e i f ( item . e q u a l s ( ” v e g g i e ” ) ) { p i z z a = new V e g g i e P i z z a ( f a c t o r y ) ; p i z z a . setName ( ”New York S t y l e Veggie P i z z a ” ) ; } e l s e i f ( item . e q u a l s ( ” clam ” ) ) { p i z z a = new ClamPizza ( f a c t o r y ) ; p i z z a . setName ( ”New York S t y l e Clam P i z z a ” ) ; } pizza . prepare ( factory ) ; Faysal Boukayoua

3ELICTI (2006-2007)


27

p i z z a . bake ( ) ; pizza . cut ( ) ; p i z z a . box ( ) ; return p i z z a ;

116 117 118 119

}

120 121 122

}

16.4.2 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. 16.4.3 Opmerkingen De stappen die telkens gezet werden om het voorbeeld te verfijnen zijn de volgende: 1. 2.

3.

Simple Factory: code bijeenbrengen (nieuwe klasse of statische methode) voor herbruikbaarheid 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. 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

Faysal Boukayoua

3ELICTI (2006-2007)


16.5

28

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

maakt familie gerelateerde objecten meerdere polymorfe methodes nodig 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 Listing 7: Voorbeeld van Singleton Pattern Code

1 2 3 4 5 6 7 8

public c l a s s S i n g l e t o n { private s t a t i c S i n g l e t o n i n s t a n t i e = null ; private S i n g l e t o n ( ) { } public synchronized s t a t i c S i n g l e t o n g e t I n s t a n t i e ( ) { 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 ( ) ; return i n s t a n t i e ; } }

17

Bespreek kort de Strategy, Observer en Chain of Responsibility patronen.

17.1

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:

Faysal Boukayoua

3ELICTI (2006-2007)


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: Listing 8: Chain of Responsibility: Logger 1

import j a v a . u t i l . ∗ ;

2

Faysal Boukayoua

3ELICTI (2006-2007)


3 4 5 6 7 8 9 10 11 12 13

30

public abstract c l a s s Logger { public s t a t i c int ERR = 3 ; public s t a t i c int NOTICE = 5 ; public s t a t i c int DEBUG = 7 ; protected int mask ; // t h e n e x t e l e m e n t i n t h e c h a i n o f r e s p o n s i b i l i t y protected Logger next ; public Logger s e t N e x t ( Logger l ) { next = l ; return t h i s ; } abstract public void message ( S t r i n g msg , int p r i o r i t y ) ; }

14 15 16 17 18 19 20 21 22 23 24

public c l a s s DebugLogger extends Logger { public DebugLogger ( int mask ) { t h i s . mask = mask ; } public void message ( S t r i n g msg , int p r i o r i t y ) { i f ( p r i o r i t y <= mask ) System . out . p r i n t l n ( ” Writing t o debug output : ”+msg ) ; i f ( next != null ) next . message ( msg , p r i o r i t y ) ; } }

25 26 27

public c l a s s EMailLogger extends Logger { public EMailLogger ( int mask ) { t h i s . mask = mask ; }

28

public void message ( S t r i n g msg , int p r i o r i t y ) { i f ( p r i o r i t y <= mask ) System . out . p r i n t l n ( ” Sending v i a e−m a i l : ”+msg ) ; i f ( next != null ) next . message ( msg , p r i o r i t y ) ; }

29 30 31 32 33 34 35

}

36 37 38 39

public c l a s s S t d e r r L o g g e r extends Logger { public S t d e r r L o g g e r ( int mask ) { t h i s . mask = mask ; }

40

public void message ( S t r i n g msg , int p r i o r i t y ) { i f ( p r i o r i t y <= mask ) System . out . p r i n t l n ( ” Writing t o s t d e r r : ”+msg ) ; i f ( next != null ) next . message ( msg , p r i o r i t y ) ; }

41 42 43 44 45 46 47

}

48 49

public c l a s s C h a i n O f R e s p o n s i b i l i t y E x a m p l e { Faysal Boukayoua

3ELICTI (2006-2007)


public s t a t i c void main ( S t r i n g [ ] a r g s ) { // b u i l d i n g t h e c h a i n o f r e s p o n s i b i l i t y Logger l = new DebugLogger ( Logger .DEBUG) ; Logger e = new EMailLogger ( Logger . NOTICE ) ; Logger s = new S t d e r r L o g g e r ( Logger .ERR) ; l . setNext ( e ) ; e . setNext ( s ) ; // h a n d l e d by DebugLogger l . message ( ” E n t e r i n g f u n c t i o n y . ” , Logger .DEBUG) ; // h a n d l e d by Debug− and S t d e r r L o g g e r l . message ( ” Step1 completed . ” , Logger . NOTICE ) ; // h a n d l e d by a l l t h r e e Logger l . message ( ”An e r r o r has o c c u r r e d . ” , Logger .ERR) ; }

50 51 52 53 54 55 56 57 58 59 60 61 62 63 64

31

} Dit wordt de output: Writing Writing Sending Writing Sending Writing

to debug output: to debug output: via e-mail: to debug output: via e-mail: to stderr:

Entering function y. Step1 completed. Step1 completed. An error has occurred. An error has occurred. An error has occurred.

18

Bespreek kort de Adapter, Facade en Decorator patronen.

18.1

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

• • •

Faysal Boukayoua

3ELICTI (2006-2007)


32

Figuur 5: Algemeen diagram van het adapterpatroon Listing 9: Adapter: toevoegen voor een kalkoen aan de eendjessimulatie 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

public c l a s s TurkeyAdapter implements Duck { Turkey t u r k e y ; public TurkeyAdapter ( Turkey t u r k e y ) { this . turkey = turkey ; } public void quack ( ) { turkey . gobble ( ) ; } public void f l y ( ) { for ( int i =0; i < 5 ; i ++) { turkey . f l y ( ) ; } } } public c l a s s AdapterTest { public s t a t i c void main ( S t r i n g [ ] a r g s ) { Duck d = new Duck ( ” Donald ” ) ; Turkey t = new Turkey ( ” Geraar ” ) ; TurkeyAdapter t a = new TurkeyAdapter ( t ) ; t a . quack ( ) ; ta . f l y ( ) ; } }

Faysal Boukayoua

3ELICTI (2006-2007)


33

18.1.1 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 6= 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 (2n 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,

Faysal Boukayoua

3ELICTI (2006-2007)


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 6= 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 Faysal Boukayoua

3ELICTI (2006-2007)


35

web service is a service that is accessed using standard Internet and XML-based protocols •

Engineering van services gebeurt in 6= stappen. Zie figuur 6 op de vorige pagina: – Service Candidate Identification: 1. Utility Services: algemene functionaliteit, gebruikt door verschillende services. 2. Business Services: specifieke functionaliteit, zoals studentenregistratie op univ 3. Coördinatieservices: bieden een ondersteunende werking Verdere beschouwingen kunnen zijn: ∗ gebruikt door 1 of meerdere entiteiten? ∗ taak door verschillende mensen van het bedrijf uitgevoerd (workflow services)? ∗ onafhankelijk? ∗ persistentie nodig (database)? ∗ gebruik door clients buiten de organisatie? ∗ is het waarschijnlijk 6= gebruikers ook 6= niet-functionele eisen hebben? Service Design: denken over soorten operaties en uitgewisselde berichten. Aantal – uitgewisselde berichten minimaliseren. Het is mogelijk dat er statusinfo in wordt opgenomen. ∗ Logical interface design: Service requirements, methodes, parameters en exceptions voor de service definiren en aflijnen ∗ Message Design: Ontwerp van structuur en organisatie van de input- en de outputberichten. WSDL description: Specificatie omgezet naar WSDL ∗ – Service Implementation and Deployment: ∗ programmeren met gewone programmeertaal of workflowtaal ∗ testen door output op bepaalde input evalueren deployment = installeren op webserver en publiceren met UDDI ∗ Het is belangrijk dat er voor legacy-systemen ondersteuning geboden wordt (met service interfaces toegang bieden voor de clients): dit kan de kosten van de ontwikkeling van de services drukken en voorkomen dat het oude systeem versneld afgedankt wordt (dubbele kostenbesparing).

20

Bespreek kort Aspect Oriented Programming en Aspect Oriented Software Development.

Scheiding van concerns ⇒ AO leent zich goed tot implementatie van crosscutting concerns (moeilijk in te kapselen: logging, security,...) 20.1

Aspect Oriented Programming

20.1.1 Paradigma • •

aspect: standalone module waarin crosscutting concerns in worden opgenomen join point: plaats in de uitvoering van een programma waar de advice wordt uitgevoerd (waar aspect en programma samenkomen)

Faysal Boukayoua

3ELICTI (2006-2007)


• •

36

pointcut: definitie van een set van join points advice: code die in de aspect zit en uitgevoerd moet worden

⇒ join point model (dynamisch, zoals uit volgende punten zal blijken!) In AspectJ is elke method call at runtime een verschillend join point, zelfs als ze dezelfde oorsprong in het programma. 20.1.2 Pointcuts in AspectJ • •

•

•

Gebruik van &&, k en ! mogelijk: call(void Point.setX(int)) || call(void Point.setY(int)) Gebruik van een “naam” mogelijk indien pointcut veel criteria heeft: pointcut move(): call(void FigureElement.setXY(int,int)) || call(void Point.setX(int)) || call(void Point.setY(int)) || call(void Line.setP1(Point)) || call(void Line.setP2(Point)); Mogelijkheid om wildcards te gebruiken: call(void Figure.make*(..)) call(public * Figure.* (..)) Pointcuts kunnen voorkomen in dynamische context van andere join points: cflow(move()) slaat op aanduiding van elke join point die voorkomt tussen de oproep en return (normaal of met exception) van een van de methodes uit move() (de control flow van move(), dus).

20.1.3 Advice in AspectJ • •

•

before(): before(): move() { System.out.println("about to move"); } after(): 3 soorten after-advice: – after returning – after throwing – plain after (zoals bij “finally”) around(): heeft expliciete controle over of het programma al dan niet doorgaat met uitvoeren van advice

20.1.4 Exposing context in pointcuts •

after(FigureElement fe, int x, int y) returning: call(void FigureElement.setXY(int, int)) && target(fe) && args(x, y) { System.out.println(fe + " moved to (" + x + ", " + y + ")"); }

Faysal Boukayoua

3ELICTI (2006-2007)


• •

37

Na return van een opgeroepen methode “void FigureElement.setXY(int, int)” waarvan “fe” het doel is en “x” en “y” als argumenten worden doorgegeven ⇒ System.out.println(...) Dus: niet alleen de naam speelt een rol, maar ook waar, wanneer en wat (=context). Primitieve pointcuts: “this”, “target” en “args” Zelfde als hierboven, maar hier geven we de pointcut ook een naam: pointcut setXY(FigureElement fe, int x, int y): call(void FigureElement.setXY(int, int)) && target(fe) && args(x, y); after(FigureElement fe, int x, int y) returning: setXY(fe, x, y) { System.out.println(fe + " moved to (" + x + ", " + y + ")."); }

20.1.5 Inter-type declarations in AspectJ Inter-type declarations laten toe members aan klassen toe te voegen en relaties van klassen onderling te wijzigen. Dit gebeurt at compile time en is dus statisch!! Bvb: definiëren van een attribuut in een klasse vanuit een aspect voor extra functionaliteit (klassieke manier is een interface implementeren). Listing 10: Demonstratie van inter-type declarations in AspectJ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

aspect PointObserving /∗ Enkel a s p e c t kan aan P o i n t . o b s e r v e r s = l i j s t van o b s e r v e r s d i e een punt i n de g a t e n houden ∗/ { private Vector Po in t . o b s e r v e r s = new Vector ( ) ; // t o e v o e g e n van een o b s e r v e r aan de o b s e r v e r l i j s t public s t a t i c void addObserver ( P oi nt p , S c r e e n s ) { p . o b s e r v e r s . add ( s ) ; } // v e r w i j d e r e n van een o b s e r v e r u i t de o b s e r v e r l i j s t public s t a t i c void removeObserver ( Po in t p , S c r e e n s ) { p . o b s e r v e r s . remove ( s ) ; } // d e f i n i r e n van een p o i n t c u t waar p v e r o n d e r s t e l d wordt // g e w i j z i g d t e z i j n p o i n t c u t c h a n g e s ( P oi nt p ) : target (p) && c a l l ( void Po in t . s e t ∗ ( int ) ) ;

16 17 18 19 20 21 22 23 24

//Na p o i n t c u t c h a n g e s ( p ) waar p v e r a n d e r d i s a f t e r ( P oi nt p ) : c h a n g e s ( p ) // S e q u e n t i e code voor updaten van ALLE o b s e r v e r s { Iterator i t e r = p . observers . iterator ( ) ; while ( i t e r . hasNext ( ) ) { updateObserver ( p , ( S c r e e n ) i t e r . next ( ) ) ; } } // code d i e u i t g e v o e r d wordt om t e updaten Faysal Boukayoua

3ELICTI (2006-2007)


s t a t i c void updateObserver ( Po in t p , S c r e e n s ) { s . display (p ) ; }

25 26 27

38

}

20.1.6 Aspects in AspectJ • • •

Declaratie ervan lijkt sterk op klassen ⇒ kunnen bvb. attributen en eigen methoden hebben Objectinstanties creëren is mogelijk. Echter gecontroleerd door AspectJ (geen “new”). Standaard zijn deze instanties singletons Speciale “variabele” thisJoinPoint: pointcut tracedCall(): call(void FigureElement.draw(GraphicsContext)); Indien ergens in de code een join point bereikt wordt waar voldaan wordt aan bovenstaand criterium en er is deze instructie opgegeven: System.out.println(thisJoinPoint) dan wordt dit afgedrukt: call(void FigureElement.draw(GraphicsContext))

Development aspects Gebruik van aspects bij: • • •

•

tracing: opsporen van fouten,... logging en profiling (=performance analysis) modulair definiren van pre- en post-condities (modulair moeilijk met gewone OO), die moeten vervuld zijn vooraleer bepaalde code uitgevoerd wordt, zoniet wordt bvb. een exception opgeworpen contract enforcement: ervoor zorgen dat enkel erkende factories objecten kunnen toevoegen aan een bijgehouden verzameling ⇒ zoniet is het mogelijk exceptions op te gooien of zelfs een compiler error te laten signaleren

Production aspects • • •

Change Monitoring is veel makkelijker te implementeren met AO dan gewone OO context passing consistent gedrag leveren

20.1.7 Een beetje syntax • • • • • • •

execution(void Point.setX(int)): wanneer methode wordt uitgevoerd call(void Point.setX(int)): wanneer methode wordt opgeroepen handler(ArrayOutOfBoundsException): wanneer een bepaalde exception wordt afgehandeld this(SomeType): wanneer uitvoerende code afkomstig is van een object van type SomeType target(SomeType): doelobject is van type SomeType within(MyClass): als uitvoerende code behoort tot MyClass cflow(call(void Test.main())): als de join point voorkomt in de control flow van een opgeroepen methode Test.main()

Faysal Boukayoua

3ELICTI (2006-2007)


20.2

39

Aspect Oriented Software Development

Aspects zijn overgewaaid als programmeerconcept, maar er werden aanpassingen in het ontwikkelproces gedaan, ten behoeve van een aspect-oriented aanpak. 20.2.1 Architectuur van een aspect-oriented systeem • • •

opgebouwd rond een kern met extensies de kern omvat de primary concerns extensions omvatten secondary concerns en crosscutting concerns

Types uitbreidingen: • • • •

Secondary functional extensions: extra functionaliteiten toevoegen Policy Extensions: ondersteunen een organisatiebeleid, bvb. naar veiligheid toe QoS extensions: helpen bij het leveren van de nodige kwaliteitseisen Infrastructure extensions: helpen bij de implementatie van het systeem op een ander platform

20.2.2 Toepassing AO Software Development biedt technieken voor systematische identificatie, modularisatie en compositie van crosscutting concerns Bekijken tijdens: Requirements • • •

Ruwe eisen en beperkingen Niet-functionele eisen: QoS: usability, security (komen in meerdere componenten voor) Methoden: Goal-oriented approaches: – meerdere niveaus van abstractie mogelijk ∗ ∗ goals: functioneel en niet-functioneel – Problem frames: ∗ focus op omgeving en interface ∗ =concerns behandelen als aspects – Viewpoints: ∗ scheiding van crosscutting vereisten ∗ typisch high-level niet-functionele eisen ∗ crosscutting concerns zijn concerns die als dusdanig zijn ge¨ıdentificeerd door alle viewpoints ∗ viewpoints representeren de eisen van een verwante groepen betrokkenen – aanpakken specifiek voor aspectuele eisen

Faysal Boukayoua

3ELICTI (2006-2007)


40

Figuur 7: Viewpoints vs. Concerns

Specification: nadruk op formele aanpak Design: uitbreiding OO-design en UML met mogelijkheden voor modularisering crosscutting concerns Implementation: aandacht op aspectoriented software development was oorspronkelijk hier ontstaan (uit het programmeren) Evolution • • •

60-80 % kost in onderhoud dynamic evolution: aanpassen software terwijl in werking separation of concerns zou vervangen/wijzigen/toevoegen van aspecten moeten vereenvoudigen

20.2.3 Aspect Interaction • • • • •

Nog niet in behandeling Analyse van ongewenste interacties tussen aspects aspects orthogonaal op onderliggende code, maar ze mogen niet onderling orthogonaal zijn gedrag aspect is afhankelijk van gedrag van een ander aspect? Oplossing vanuit 3 invalshoeken: – avoidance – detection – resolution

20.2.4 UML Extensions Om AO te werken in UML is nodig: • •

aspecten kunnen modelleren join points kunnen opgeven

Faysal Boukayoua

3ELICTI (2006-2007)


41

20.2.5 Validatie, verificatie en tests •

•

•

Wat? – Verificatie: checken of programma voldoet aan specificatie – Validatie: checken of programma voldoet aan de echte behoeften van de betrokkenen – Zowel white- als blackbox testing blackbox tests: geen probleem, whitebox tests wel: – hoe aspects specifiëren zodat men er tests voor kan ontwerpen? aspects onafhankelijk van basissysteem testen? – – testen van interferentie van aspects? – kan men alle wegen testen die het programma uitvoert (grafen uittekenen voor het programma is onmogelijk)? – Wat met de aspects die meerdere keren worden uitgevoerd? AO programma’s slecht leesbaar vergeleken met OO (web van code)

Faysal Boukayoua

3ELICTI (2006-2007)

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

Recommend Documents