Transcript Analyse I - Dominic Meulemans

OO Analyse
in de praktijk
I Inleiding & dX
Inhoudstafel

Inleiding
3 klassieke stadia
 Literatuurgeschiedenis
 Wat maakt het verschil (Critical Succes Factors)
 Enkele anti-patterns en code smells vooraf


Het proces: Extreme programming en dX
Iteratieve ontwikkeling
 Planning
 Wat gebeurt er in 1 iteratie

OO Analyse, I Inleiding & dX
2
3 klassieke stadia in softwareontwikkeling

0 Achtergrond (hier wordt zelden over gesproken)




1 Conceptie



=klassieke analyse in enge zin
Heeft geen zin zonder vorige fase
2 Design/Specificatie


=kennis van het onderwerp
=belangrijkste fase
Wordt vaak vergeten !
Bevat al sommige implementatiebeslissingen
3 Implementatie
Belangrijker dan veel managers denken
OO Analyse, I Inleiding & dX
3
Opmerkingen




Stadia hoeven niet in volgorde doorlopen te
worden
WEL weten op welk niveau je bezig bent
Analyse ≠ exacte wetenschap. Informatica is te
jong. Enig criterium: BRUIKBAARHEID
Implementatiefase is WEL belangrijk. Hier kan
het nog altijd fout gaan.
OO Analyse, I Inleiding & dX
4
Literatuur voor deze cursus:
UML is in principe een notatie, onafhankelijk van het te volgen
proces. Maar de meeste boeken erover, hebben het ook over het
te volgen proces.

UML distilled, Martin Fowler


Notatie bruikbaar voor fases 1 & 2
UML for Java programmers, Robert C. Martin

Fases 2 & 3
OO Analyse, I Inleiding & dX
5
Literatuur

’50ies en ’60ies: Vroege werken ivm Simula ,
Nygaard & Dahl
Fase 3, programmeren van simulaties
 1e echte OO taal, werd inspiratie voor OO Analyse


1991: Object-Oriented Analysis, Coad &
Yourdon
Fase 1
 Kort & eenvoudig maar theoretisch

OO Analyse, I Inleiding & dX
6
Literatuur

1985: Eiffel, A Language for Software
Engeneering, Bertrand Meyer


Fase 3, maar ook 1 en 2 (dat is juist de clou)
1988: OO Software Construction, Bertrand
Meyer
Fase 1, 2 en 3
 Klassieker, dik boek, vrij moeilijk, vol humor, héél
overtuigend en enthousiasmerend

OO Analyse, I Inleiding & dX
7
Literatuur

1994: Object Oriented Analysis & Design with
Applications, Grady Booch




Fase 1 & 2
Klassieker. dik boek, moeilijk, droog.
Bevat wel nuttige informatie voor wie jaren bezig is.
1994: Design Patterns, Gamma & Helm & Johnson &
Vlissides


Fase 2, ook wel 3
Focust op design. Is gestructureerde no nonsense cataloog
van OO ontwerp-patronen. Moeilijk maar interessant boek.
OO Analyse, I Inleiding & dX
8
Literatuur

1999: Refactoring, Improving the Design of Existing
Code, Martin Fowler




Fase 3, ook wel 2
Behandelt nauwgezet hoe je slechte code omzet tot goede.
Bevat veel herkenbaars voor wie ooit bestaande code heeft
moeten aanpassen.
Benadrukt belang van automatisch testen.
Andere auteurs: Kent Beck, Ivar Jacobson, Barbara
Liskov, James Rumbaugh, Bjarne Straustrup (C++), …
OO Analyse, I Inleiding & dX
9
Wat maakt het verschil…
…tussen een geslaagd project en een fiasco. De Critical
Succes Factors voor software engeneering:

Respect voor


de klant
de technologie. Welke technologie is minder belangrijk





procedureel programmeren versus OO programmeren
relationele databases versus OO databases
Java versus VB versus C++ enz
blote hand versus GUI-tools
jezelf en de andere team-leden.

Als je niet meer gemotiveerd bent, moet je snel iets anders doen.
OO Analyse, I Inleiding & dX
10
Wat maakt het verschil (vervolg)

Achtergrondkennis over de Business &
Communicatie met de klant
o.a. kennis van de Requirements
 Er zijn prachtige systemen zijn ontwikkeld, waar
niemand naar gevraagd heeft (zie volgende slide)

OO Analyse, I Inleiding & dX
11
Wat maakt het verschil (vervolg)
OO Analyse, I Inleiding & dX
12
Wat maakt het verschil (vervolg)

Geautomatiseerde Tests
Maken continue verbetering van de architectuur van
de code mogelijk.
 Geven aan in welke mate aan de specificaties voldaan
is.

OO Analyse, I Inleiding & dX
13
Wat maakt het verschil (vervolg)

Omkadering



Charismatische projectleider die echt meewerkt en
waar iedereen naar opkijkt.
Project-planning: Duidelijke en eenvoudig te
verifiëren mijlpalen.
Methodologie-proces: Sluit aan bij bovenste. Er
moet een algemeen aanvaarde praktische werkwijze
zijn.
OO Analyse, I Inleiding & dX
14
Wat maakt het verschil (vervolg)

Vermijden van Copy-Paste code
Lijkt een detail, maar is het niet.
 Copy-Paste programmering is DE oorzaak van falen
in fase 3 bij grote projecten. Geeft aanleiding tot
exponentieel groeiende code: x2, x4, x8, x16, x32
…→ ∞, dit is niet meer te managen.
 Neem zoveel mogelijk gemeenschappelijke code
samen en roep deze op of gebruik de componenten.

OO Analyse, I Inleiding & dX
15
Enkele anti-patterns en code smells.
I Anti-patterns
Anti-pattern: vaak voorkomende foute oplossing
Code smell: verdachte code (Fowler, Beck)
OO Analyse, I Inleiding & dX
16
Anti-patterns (vervolg)

Anti-patterns
Bloemlezing uit het boek Anti Patterns van
Brown, Malveau,…:
The Blob: monolitisch onverdeelde gigantische
procedure of klasse
 Lava Flow
 Golden Hammer: alles willen doen met 1 heilige
tool. Vb alles met Excel macro’s, alles met HTML

OO Analyse, I Inleiding & dX
17
Anti-patterns (vervolg)
Spaghetti-code
 Cut & paste programming (eerder vernoemd)
 Vendor Lock-In
 Design by committee
 Reinvent the Wheel
 Analysis Paralysis

OO Analyse, I Inleiding & dX
18
Code smells
Term gebruikt door Kent Beck & Martin Fowler
Duplicate code (copy paste, zie boven)
 Te veel parameters
 Te veel properties (data-fields)
 Te veel code in 1 klasse
 Te veel gelijkende klassen (zie copy paste enz)

OO Analyse, I Inleiding & dX
19
Code smells, (vervolg)
Data-klassen: zonder methoden
 Method-klassen: zonder data-fields. Pot met functies.
 Cryptische naamgeving
 Nodeloze documentatie


Oorzaak: Unconscious Incompetence
http://c2.com/cgi/wiki?UnconsciousIncompetence
OO Analyse, I Inleiding & dX
20
Het proces: Extreme Programming
(Kent Beck) en dX
We beschrijven hier de versie dX van
Robert C. Martin © Copyright 2003.
OO Analyse, I Inleiding & dX
21
Extreme Programming (Kent Beck)
en dX
Structuur
 Iteratieve ontwikkeling, algemeen

Initiële exploratie (1e iteratie)



Schattng van de features
Callibreren van de schattingen
Planning (vanaf 2e iteratie)




Planning Releases
Planning Iteraties
Middelpunt (aanpassing van de ambities)
Dag 10 Feedback over de snelheid:
OO Analyse, I Inleiding & dX
22
Extreme Programming (Kent Beck)
en dX
Structuur (vervolg):
 Wat gebeurt er in 1 iteratie
Algemeen
 Praktijken of gewoontes

Pair Programming
 Acceptatiestests
 Unit Tests
 Refactoring
 Open Office
 Continue Integratie

OO Analyse, I Inleiding & dX
23
Iteratieve ontwikkeling

Iteratieve ontwikkeling, algemeen
ALLES in 2 weken doen: requirements, analyse, ontwerp,
implementatie, testen, documentatie.
Elke 2 weken eindigen in uitvoerbare code
1 uitzondering: de eerste iteratie is korter (3 dagen) en hoeft
geen code te bevatten.
 Initiële exploratie (3 dagen)
Requirements en prioriteiten bepalen met de klant
User stories bepalen (=1 manier om het systeem te gebruiken)
Deze activiteiten zullen in alle iteraties herhaald worden
OO Analyse, I Inleiding & dX
24
Iteratieve ontwikkeling (vervolg)

Initiële exploratie (vervolg)

Schatting van de features




Elke story krijgt een schatting in ‘punten’ van het werk nodig om
deze story te implementeren
Dimensieloos getal: eventueel ‘perfecte programmeerdagen’
1 à 2 teamdagen per story
Callibreren van de schattingen


Initiële exploratie eindigt eventueel met werkende code
Doel: Bepalen hoeveel mandagen 1 punt is
OO Analyse, I Inleiding & dX
25
Wat gebeurt er in 1 iteratie
1 iteratie = 2 weken
 Algemeen
Alle fases doorlopen: analyse resuirements, design &
implementation
 ALLEEN voor de door de klant gekozen user
stories
 Belangrijkste stories worden op die manier eerst
behandeld

OO Analyse, I Inleiding & dX
26
Wat gebeurt er in 1 iteratie (vervolg)

Praktijken of gewoontes:

Pair-programming
2 programmeurs per werkstation
 1 programmeur blijft bij zijn task
 Elke dag een andere partner
 Voordelen: automatische code reviews, ene
programmeert, andere beoordeelt, bevordert
communicatie, vermijdt domme fouten

OO Analyse, I Inleiding & dX
27
Wat gebeurt er in 1 iteratie (vervolg)
Praktijken of gewoontes (vervolg):
 Acceptatietests:
 Tests
die nagaan of de code voldoet aan de eisen
die vooropgesteld zijn. Acceptatietests omvatten
grotere gehelen (stories)
 Halverwege 1 iteratie (na 1 week) moeten ze
beschikbaar zijn
OO Analyse, I Inleiding & dX
28
Wat gebeurt er in 1 iteratie (vervolg)
Praktijken of gewoontes (vervolg):
 Unit tests:
Tests die om de pakweg 5 minuten lopen, terwijl je
programmeert
 Ze zijn geautomatiseerd. Je hoeft geen schermen tekst te
controleren. compare & report gebeuren automatich.
 Je schrijft deze tests VOOR je de code intikt die getest
wordt
 Ze zijn een vorm van documentatie van de specificaties en
een aanwijzing dat er aan voldaan is. De tests moeten
daarom ook betekenisvolle identifiers bevatten.

OO Analyse, I Inleiding & dX
29
Wat gebeurt er in 1 iteratie (vervolg)
Praktijken of gewoontes (vervolg):
 Refactoring
=
Verbetering van bestaande code zonder het
gedrag naar buiten toe te wijzigen. (Zie supra
Martin Fowler )
 Geautomatiseerde tests maken refactoring
mogelijk.
OO Analyse, I Inleiding & dX
30
Wat gebeurt er in 1 iteratie (vervolg)
Praktijken of gewoontes (vervolg):
 Open Office

Iedereen zit in dezelfde zaal. Ook de klant ! Dit voor een
goede communicatie.
 Continue
integratie
Niemand kan source-files blokkeren. (Version Control) ->
Veel merges nodig. N.B.Dit punt is controversieel maar
nodig voor het 2e punt.
 Alvorens in te checken, draait elke programmeur ALLE
unit & acceptance tests.

OO Analyse, I Inleiding & dX
31