Hoe snel loopt iemand de 100 meter
This presentation is the property of its rightful owner.
Sponsored Links
1 / 31

Hoe snel loopt iemand de 100 meter ? PowerPoint PPT Presentation


  • 66 Views
  • Uploaded on
  • Presentation posted in: General

Hoe snel loopt iemand de 100 meter ?. 4. Planning. Tijdsschatting Analogie & Decompostie Empirische schatting Plan 2.0 & Plan 2.1 Conclusie versie 1.7 en 1.8 (Player. winner()) Enkele vuistregels Hollywood principe 3-lagen architectuur

Download Presentation

Hoe snel loopt iemand de 100 meter ?

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Hoe snel loopt iemand de 100 meter

Hoe snel loopt iemand de 100 meter ?

Planning


4 planning

4. Planning

  • Tijdsschatting

    • Analogie & Decompostie

    • Empirischeschatting

      • Plan 2.0 & Plan 2.1

  • Conclusie

  • versie 1.7 en 1.8 (Player. winner())

  • Enkelevuistregels

    • Hollywood principe

    • 3-lagen architectuur

      • ⇒ invoer tests + uitvoer tests + domein test

    • Contracten & Interface

  • Makefiles

Planning


Ontwikkel vereisten

"Ontwikkel" vereisten

  • Vereisten

  • Betrouwbaarheid

  • Aanpasbaarheid

  • Planning

  • Technieken

  • Testen + Contracten

  • Objectgericht ontwerp

  • Tijdsschatting

Planning


Schatting door analogie

Schatting door analogie

Analogie

  • Schatting = tijd gelijkaardig project

  • Wanneer gelijkaardig ?

    • Zelfde probleemdomein

    • Zelfde mensen

    • Zelfde technologie

Empirisch

gespendeerde tijd voorbije projecten dient als basis voor schatting volgende

Planning


Empirische schatting project

Empirische schatting (project)

Schat totale duur van project op basis van vorige projecten

y = a x b

(b ±= 1)

Y

Legende

Ontwikkeltijd

= Voorbij

= Prognose

X

Grootte project

Planning


Schatting door decompositie

Schatting door decompositie

Decompositie

  • Schatting = tijdcomponenten+ integratiekost

  • Tijdcomponenten ?

    • cfr. opgeleverdecomponenten

  • Integratiekost ?

    • constant (mitstesten en OO)

Empirisch

gespendeerde tijd eerste componenten dient als basis voor schatting volgende

Planning


Empirische schatting component

Y

X

Empirische schatting (component)

Schat duur van één component op basis van opgeleverde componenten

y = m x

Legende

Ontwikkeltijd component

= Opgeleverd

= Prognose

Grootte component

Planning


Grootte en tijd

x = Grootte Component ?

# stappen + #uitzonderingenin use case

y = Ontwikkellingstijd ?

Zie tijdsbladen

Grootte en Tijd

vergelijking benaderende rechte

y = mx

Na opleveringncomponenten: (xn, yn)⇒ m= ∑ yn / ∑ xn

Schatting yn+1voorgrootte xn+1⇒ yn+1 = m.xn+1

Planning


Vuistregel

Vuistregel

Empirische schatten is de basis voor een realistische planning.

  • Waarom ?

  • Betere controle over aanpassingen aan de planning

  • Hoe ?

  • Hou tijdsbladen nauwkeurig bij

  • Maak prognose op basis van gespendeerde werk in het verleden

Planning


Use case grootte

play

player

Use Case Grootte

  • Use Case 1: play

  • Steps

  • 1. Two players start up a game(First is "O"; other is "X")

  • 2. WHILE game not done

    • 2.1 Current player makes move

    • 2.2 Switch current player

  • 3. Anounce winner

  • Exceptions

  • 2.1. [Illegal Move] System issues a warning=> continue from step 2.1

#stappen = 5

#uitzond. = 1

grootte = 6

Planning


Voorbeelden

Voorbeelden

Zie voorbeelden in PlanTmpl20 & PlanTmpl21

Planning


Conclusie

Conclusie

  • Betrouwbare prognoses zijn belangrijk

    • Hou tijdsbladen nauwkeurig bij !

  • Schatten impliceert fouten

    • Voorzie een redelijke marge

    • Vertrouw niet blindelings op de cijfertjes

Planning


Tictactoe17

TicTacToe17

  • class TicTacToe {

  • ...

  • private:

  • char _winner;

  • };

  • TicTacToe::TicTacToe() {

  • _winner = ' ';

  • ENSURE(properlyInitialized(), "constructor …");

  • }

  • void TicTacToe::writeOn(std::ostream& onStream) {

  • onStream << "TicTacToenumberOfMoves = " << this->nrOfMoves()

  • << " - winner = '" << this->getWinner() << "'" <<std::endl;

  • }

winnaar toevoegen impliceert

- aanpassingen aan de constructor

- aanpassingen aan “writeOn”

⇒ Testen en HappyDayOutput

+ nieuwe testen voor getWinner

Planning


Tictactoe18

TicTacToe

TicTacToe();

setMoves (oMoves, xMoves: STRING)

getMark(col, row: CHAR): CHAR

setMark (col, row, marker: CHAR): CHAR

notDone(): BOOLEAN

nrOfMoves(): INTEGER

doMove ()

writeOn(o: ostream)

getWinner (): CHAR

reset()

TicTacToe18

Testscenarios + klasseonder test

gaan hand in hand

Eenvoudigtesten van getWinner⇒ reset functionaliteit

Planning


Vuistregel1

Vuistregel

“Hollywood Principe”

don't call us, we'll call you !

  • Waarom ?

  • Uitbreiding van bibliotheken via subklasses

  • Hoe ?

  • Superklasse in bibliotheeklegt protocol van oproepen vast

  • Subklassenkunnengedraguitbreiden

    • Voorbeeld: UnitTest(mindere mate TinyXML)

Planning


Generisch unittest protocol

XxxTest

setUp()

tearDown()

TEST_F(…)

bool EXPECT_EQ(…)

bool EXPECT_TRUE(…)

GenerischUnittest Protocol

objectunder test

:XxxTest

SetUp()

…constructor + initialisatie …

testXXXX()

run()

xxx1stStimulus

EXPECT_EQ(xxx1stObservation)

xxx2ndStimulus

EXPECT_TRUE(xxx2ndObservation)

TearDown()

Er zijn veel test-methoden (testcode ≥ basiscode)

Hoe organiseren ?

Planning


Vuistregel2

Vuistregel

“3 lagenarchitectuur”

apartecomponenten (en tests !) voor

(a) presentatie,

(b) domeinlogica,

(c) data-opslag

  • Waarom ?

  • lokaal effect van veranderingen

  • Hoe ?

  • Domeinmodelhangtnietaf van databank, noch user-interface

    • ⇒ Aparte tests voorinvoer / uitvoer / domein

Planning


3 lagen architectuur

3-lagen architectuur

presentatie

uitvoertests

domeinlogica

domeintests

invoertests

opslag

Planning


Invoer tests

play

player

Invoer Tests

  • Use Case 1: play

  • Steps

  • 1. Two players start up a game(First is "O"; other is "X")

  • 2. WHILE game not done

    • 2.1 Current player makes move

    • 2.2 Switch current player

  • 3. Anounce winner

  • Exceptions

  • 2.1. [Illegal Move] System issues a warning=> continue from step 2.1

tijdens 2.1 kan

"Illegal Move"

voorkomen

Planning


Vuistregel3

Vuistregel

Minstenséén test persoort "foute" invoer

  • Waarom ?

  • Alle scenarios in de specificatiesmoetengetestworden

  • Hoe ?

  • Controleerresultaatuitzondering via "EXPECT_EQ" …=> denkeraan: " Een test produceertzoweinigmogelijkuitvoer"

Planning


Invoertests

invoertests

meerdere foutboodschappen

domein

model

domeinmodelklasse 1

domeinmodelklassen

partieeldomeinmodel

+ foutboodschappen

waardes “aan de rand”

van wat toegelaten is

foutboodschap, zonderdomeinmodel

XML met syntax fouten

(haakjes, tags, …)

XML zonderfouten

(klassen)

XML bestanden

XML met semantische

fouten (…)

XML zonderfouten

(klasse 1)

Planning


Vuistregel4

Vuistregel

Klassen die vaakgebruiktwordenhebbenpreciesecontracten (en veel tests)

  • Waarom ?

  • Beterebetrouwbaarheid door preciezebeschrijving interface

  • Hoe ?

  • Leg de “normale” volgorde van oproepen vast

  • Specifieervolgorde via de respectievelijke pre- en postcondities

  • Schrijf tests die de volgorde (pre- en post-condities) verifiëren

Planning


Contracten tests list double linked

Contracten & Tests “List” (Double Linked) ?

class node

{

public:

int value;

node *next;

node *prev;

};

class list

{

public:

node *front;

node *back;

list()

void insertFront(int value);

void insertBack(int value);

void removeFront();

void removeBack();

void insertBefore(int value, node *nodeB);

void insertAfter(int value, node *nodeA);

void removeBefore(node *nodeB);

void removeAfter(node *nodeA);

void removeNode(node *newNode);

void printDListFront();

void printDListBack();

};

Contracten ? Tests ?

Moeilijkwant interface zonderpredicaten

Planning


Lijst met predicaten

“Lijst” met predicaten

list()

//ENSURE(properlyInitialized(), "constructor must end in properlyInitialized state");

includes (int value): BOOLEAN;

//REQUIRE(this->properlyInitialized(), "list wasn't initialized when calling includes");

insert (int value);

//REQUIRE(this->properlyInitialized(), "list wasn't initialized when calling insert");

//REQUIRE(~includes(int), "before insert the list should NOT include the inserted value");

//ENSURE(includes(int), "after insert the list should include the inserted value");

delete (int value);

//REQUIRE(this->properlyInitialized(), "list wasn't initialized when calling delete");

//REQUIRE(includes(int), "before delete the list should include the inserted value");

//ENSURE(~includes(int), "after insert the list should NOT include the inserted value");

Contracten ? Tests ?

Makkelijkerwant interface met veelpredicaten

Planning


Vuistregel5

Vuistregel

Prefereer een interface met predicaten

  • Waarom ?

  • Betere betrouwbaarheid door eenvoudige contracten

  • Hoe ?

  • Specifieer predicaten voor hoofdfunctionaliteit component

  • Roep predicaten op in pre- en post-condities

Planning


Vuistregels

Betrouwbaarheid

Invoertests: Minstenséén test per soort "foute" invoer

Klassen die vaakgebruiktworden: preciesecontracten + veel tests

Prefereereen interface met predicaten

Ontwerpen

“Hollywood Principle” – wijroepenjouw op als we je nodighebben

“3 lagenarchitectuur”

apartecomponentenvoor (a) presentatie,(b) domeinlogica, (c) data-opslag

Plannen

Empirischeschatten is de basis vooreenrealistische planning

Vuistregels

Planning


Evaluatie criteria

Evaluatie Criteria

Invoertests: Minstenséén test per soort "foute" invoer

Klassen die vaakherbruiktworden (o.a. lijsten): contracten & tests

Prefereereen interface met predicaten

Empirischeschatten is de basis vooreenrealistische planning

Organisatie van componenten & tests

“Hollywood Principle”

“3 lagenarchitectuur”

Planning


Hoe snel loopt iemand de 100 meter

Make

Planning


Build rules

BuildRules

target : dependsupon

buildrule(s)

%.o : %.cpp %.h

g++ -I../gtest/include -c -o $@ $<

TicTacToeMain : TicTacToe.oTicTacToeMain.o

g++ -o $@ TicTacToe.oTicTacToeMain.o

  • een.o file is afhankelijk van .hen.cpp file

    • compileren met de juiste parameters

  • De main file is afhankelijk van alle .o files

    • linken met de juiste parameters

Planning


Build rules 2

BuildRules (2)

.PHONY: non file targets

buildrule(s)

.PHONY : clean

clean :

rm -f *.oTicTacToeMainTicTacToeTests

rm -ftestOutput/file*.txt

  • .PHONY is eenconventieom build targets temarkeren die *geen* bestandenzijn

    • De rule zal *altijd* afvuren

  • Vaakgebruikte .PHONY targets

    • all clean install

Planning


Build rules 3

BuildRules (3)

varname = variable contentscall $(varname)

CXXFLAGS =-O2 -g -Wall -fmessage-length=0 -I$(INCL)

OBJS =TicTacToe.o

SRCS =TicTacToe.cpp \

TicTacToeMain.cpp \

TicTacToeTests.cpp

TicTacToeMain : $(OBJS) TicTacToeMain.o

$(CXX) $(CXXFLAGS) -o $@ $(OBJS) TicTacToeMain.o

\ omtesplitsen over

meerderelijnen

Planning


  • Login