Inleiding Software Engineering Universiteit AntwerpenPlanning 4.1 Hoe snel loopt iemand de 100 meter ?

Presentatie over: "Inleiding Software Engineering Universiteit AntwerpenPlanning 4.1 Hoe snel loopt iemand de 100 meter ?"— Transcript van de presentatie:

1 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.1 Hoe snel loopt iemand de 100 meter ?

2 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.2 4. Planning Tijdsschatting –Analogie & Decompostie –Empirische schatting Plan 2.0 & Plan 2.1 Conclusie TicTacToe –Code Hergebruik => TestCase –HTML Uitvoer => polymorfisme –“Undo” => Lijsten & polymorfisme

3 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.3 "Ontwikkel" vereisten Vereisten Betrouwbaarheid Aanpasbaarheid Planning Technieken Testen + Contracten Objectgericht ontwerp Tijdsschatting

4 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.4 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

5 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.5 Empirische schatting (project) Grootte project Ontwikkeltijd = Voorbij = Prognose Legende y = a x b (b ±= 1) Schat totale duur van project op basis van vorige projecten X Y

6 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.6 Schatting door decompositie Decompositie Schatting = tijd componenten + integratiekost Tijd componenten ? –cfr. opgeleverde componenten Integratiekost ? –constant (mits testen en OO) Empirisch gespendeerde tijd eerste componenten dient als basis voor schatting volgende

7 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.7 Empirische schatting (component) Grootte component Ontwikkeltijd component = Opgeleverd = Prognose Legende y = m x Schat duur van één component op basis van opgeleverde componenten X Y

8 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.8 Grootte en Tijd x = Grootte Component ? # stappen + #uitzonderingen in use case y = Ontwikkellingstijd ? Zie tijdsbladen Na oplevering n componenten: (x n, y n )=> m = ∑ y n / ∑ x n Schatting y n+1 voor grootte x n+1 => y n+1 = m.x n+1 vergelijking benaderende rechte y = mx

9 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.9 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

10 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.10 Use Case Grootte play player 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

11 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.11 Voorbeelden Zie voorbeelden in PlanTmpl20 & PlanTmpl21

12 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.12 Conclusie Betrouwbare prognoses zijn belangrijk –Hou tijdsbladen nauwkeurig bij ! Schatten impliceert fouten –Voorzie een redelijke marge –Vertrouw niet blindelings op de cijfertjes

13 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.13 Code Hergebruik TicTacToeTest is groot code leesbaarheid hergebruik ? copy + delete + insert Aanpasbaarheid :( TicTacToeTest setUp() tearDown() init() fail(msg: ARRAY OF CHAR) should(b: BOOLEAN, msg: ARRAY OF CHAR): BOOLEAN shouldNot(b: BOOLEAN, msg: ARRAY OF CHAR): BOOLEAN compareFiles(fileName1, fileName2: ARRAY OF CHAR): BOOLEAN testBasicPlayer(verbose: BOOLEAN): BOOLEAN testLegalMoves(verbose: BOOLEAN): BOOLEAN testRealGame(verbose: BOOLEAN): BOOLEAN testOutputGame(verbose: BOOLEAN): BOOLEAN

14 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.14 UnitTest setUp() tearDown() init() fail(msg: ARRAY OF CHAR) should(b: BOOLEAN, msg: ARRAY OF CHAR): BOOLEAN shouldNot(b: BOOLEAN, msg: ARRAY OF CHAR): BOOLEAN compareFiles(fileName1, fileName2: ARRAY OF CHAR): BOOLEAN TicTacToeTest setUp() tearDown() init() testBasicPlayer(verbose: BOOLEAN): BOOLEAN testLegalMoves(verbose: BOOLEAN): BOOLEAN testRealGame(verbose: BOOLEAN): BOOLEAN testOutputGame(verbose: BOOLEAN): BOOLEAN UnitTest is superklasse bevat algemene code hergebruik ? subklasse per te testen component/klasse Code Hergebruik TicTacToeTest is subklasse erft algemene code overschrijft setup, init & teardown bevat alleen relevante code

15 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.15 Vuistregel “Hollywood Principle” wij roepen jouw op als we je nodig hebben Waarom ? Uitbreiding van bibliotheken via subklasses Hoe ? Superklasse in bibliotheek legt protocol van oproepen vast Subklassen kunnen gedrag uitbreiden

16 Inleiding Software Engineering Universiteit AntwerpenBetrouwbaarheid 2.16 Generisch Unittest Protocol UnitTest setUp(testCase: ARRAY OF CHAR) run() tearDown() should (…): BOOLEAN shouldNot (…): BOOLEAN object under test : UnitTest testXXXX() xxx1stStimulus setUp("testXXX") run() shouldNot(xxx1stObservation) tearDown() NEW(); init(); should(xxx2ndObservation) xxx2ndStimulus Evaluatie Criteria Obj. Collaboratie

17 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.17 Vuistregel Klassen die vaak herbruikt worden hebben preciese contracten Waarom ? Betere betrouwbaarheid door precieze beschrijving interface Hoe ? Leg de “normale” volgorde van oproepen vast Specifieer volgorde via de respectievelijke pre- en postcondities

18 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.18 Oproepvolgorde voor “UnitTest” Init() Setup Initialized SetUp() Running Run() TornDown TearDown()

19 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.19 Contracten voor “UnitTest” PROCEDURE (aTest : UnitTest) Init; (* postcondition (120): aTest^.IsInitialized() *)(* postcondition (120): ~ aTest^.IsSetup() *) (* postcondition (120): ~ aTest^.IsRunning() *)(* postcondition (120): aTest^.IsTornDown() *) PROCEDURE (aTest : UnitTest) SetUp (testCase: ARRAY OF CHAR); (* precondition (100): aTest^.IsInitialized() *)(* precondition (100): aTest^.IsTornDown() *) (* precondition (100): LEN(testCase) < MaxTestCaseLength *) (* postcondition (120): aTest^.IsSetup() *)(* postcondition (120): ~ aTest^.IsTornDown() *) PROCEDURE (aTest : UnitTest) Run; (* precondition (100): aTest^.IsInitialized() *)(* precondition (100): aTest^.IsSetup() *) (* postcondition (120): ~ aTest^.IsSetup() *)(* postcondition (120): aTest^.IsRunning() *) PROCEDURE (aTest : UnitTest) TearDown; (* precondition (100): aTest^.IsInitialized() *)(* precondition (100): aTest^.IsRunning() *) (* postcondition (120): ~ aTest^.IsRunning() *)(* postcondition (120): aTest^.IsTornDown() *)

20 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.20 Vuistregel Schrijf testcode als subklasse(n) van “UnitTest” Waarom ? Betere onderhoudbaarheid van de testcode Hoe ? Maak een subklasse van “UnitTest” per te testen component Overschrijf Init(), SetUp(), TearDown(), Run ()

21 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.21 HTML Uitvoer (TTT16b) play player Use Case 3: play HTML output Extension of use case 1 Steps use case 1 + additional steps afer 2.2 2.3 write game on HTML (table) during 3 3 write winner on HTML text play HTML output > (Erg gelijkaardig aan use case 2) => inheritance & polymorfisme ?

22 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.22 PROCEDURE (aTicTacToe: TicTacToe) writeHTMLOn* (VAR w: Texts.Writer); … BEGIN Texts.WriteString(w, " "); Texts.WriteString(w, "TicTacToe game after move "); Texts.WriteInt(w, aTicTacToe.nrOfMoves, 0); Texts.WriteString(w, " ");Texts.WriteLn(w); FOR i := 0 TO 2 DO Texts.WriteString(w, " ");Texts.WriteLn(w); FOR j := 0 TO 2 DO Texts.WriteString(w, " "); … END; … "Ongeveer" gelijk aan writeOn => duplicatie

23 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.23 PROCEDURE (aTest: TicTacToeTest) testOutputGame* (… writeHTML: BOOLEAN): BOOLEAN; … IF writeHTML THEN Texts.WriteString(w, " ");Texts.WriteLn(w); … END; WHILE aTest.aGame.notDone() DO aTest.aGame.doMove(); IF writeHTML THEN aTest.aGame.writeHTMLOn(w); ELSE aTest.aGame.writeOn(w); END; END; IF writeHTML THEN Texts.WriteString(w, " ");Texts.WriteLn(w); END; … => complexe conditionele logica

24 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.24 Vuistregel Vermijd code duplicatie & complexe logica Refactor: code duplicatie: gelijkaardige code in de superklasse; verschillen in subklassen complexe logica: normaal geval in de superklasse; speciale gevallen in de subklassen

25 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.25 Splits Klassen (TTT16) TicTacToeOutput startPage() endPage() startBoard() endBoard() startRow(row: CHAR) endRow() boardLocation(row, column, marker: CHAR) TicTacToeOutput TicTacToe writeOn() writeHTMLOn() TicTacToe TicTacToeHTMLOutput TicTacToeTest testOutputGame() TicTacToeTest Evaluatie Criteria printobjecten/iterators

26 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.26 PROCEDURE (aTest: TicTacToeTest) testOutputGame* (… writeHTML: BOOLEAN): BOOLEAN; … Texts.OpenWriter(w); output.init (); output.startPage(w); WHILE aTest.aGame.notDone() DO aTest.aGame.doMove(); aTest.aGame.writeOn(w, output) END; output.endPage(w); complexe condities => polymorfisme

27 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.27 PROCEDURE (aTicTacToe: TicTacToe) writeOn* (VAR w: Texts.Writer; output: TicTacToeOutput.TicTacToeOutput); BEGIN output.startSentences(w); Texts.WriteString(w, "TicTacToe game after move "); Texts.WriteInt(w, aTicTacToe.nrOfMoves, 0); output.endSentences(w); output.startBoard(w); FOR i := 0 TO 2 DO output.startRow(w, CHR(ORD("1") + i)); FOR j := 0 TO 2 DO output.boardLocation(…); END; output.endRow(w); END; output.endBoard(w); extra parameter controleert verschil verschillen in gedupliceerde code => polymorfisme

28 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.28 “Undo” play player Use Case 4: play with undo option Extension of use case 1 Steps use case 1 + additional steps afer 2.1 2.1.1 current player “undo” move 2.1.2 goto 2 (restart while loop) play with undo option >

29 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.29 “Undo” Algoritme ? Hou een lijst bij met verloop spelstatus TicTacToeData* = RECORD (OOLists.NodeDesc) nrOfMoves: INTEGER; board: ARRAY 3, 3 OF CHAR; players: ARRAY 2 OF Player; lastCol, lastRow, lastMark : CHAR; theWinner: Player; END; Herbruik bestaande code Maar … “Klassen die vaak herbruikt worden hebben preciese contracten”

30 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.30 Contracten voor “OOLists” ? PROCEDURE (l : List) Init (); PROCEDURE (l : List) LocateFirst (); PROCEDURE (l : List) LocateLast (); PROCEDURE (l : List) LocateNode (n: Node); PROCEDURE (l : List) LocatePrev (); PROCEDURE (l : List) LocateNext (); PROCEDURE (l : List) InsertBefore (new: Node); PROCEDURE (l : List) InsertAfter (new: Node); PROCEDURE (l : List) Delete (); PROCEDURE (l : List) GetNode (): Node; PROCEDURE (l : List) Enumerate (P: NodeProc); PROCEDURE (n : Node) NodeInfo (); Contracten ? Moeilijk want interface zonder predicaten

31 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.31 “Lijst” met predicaten PROCEDURE (l : List) Init (); (* postcondition (120): l^.IsInitialized() *) PROCEDURE (l : List) Includes (n: Node): BOOLEAN; (* precondition (100): l^.IsInitialized() *) PROCEDURE (l : List) Insert (new: Node); (* precondition (100): l^.IsInitialized() *) (* postcondition (120): l^.Includes(new) *) PROCEDURE (l : List) Delete (old: Node); (* precondition (100): l^.IsInitialized() *) (* postcondition (120): ~ l^.Includes(new) *) Contracten ? Makkelijker want interface met veel predicaten Evaluatie Criteria Reuse (lijsten)

32 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.32 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

33 Inleiding Software Engineering Universiteit AntwerpenPlanning 4.33 Vuistregels Testen Schrijf testcode als subklasse(n) van “UnitTest” Ontwerpen Vermijd code duplicatie & complexe logica “Hollywood Principle” – wij roepen jouw op als we je nodig hebben Klassen die vaak herbruikt worden hebben preciese contracten Prefereer een interface met predicaten Plannen Empirische schatten is de basis voor een realistische planning