Program Realisation 2 Todays Topics Pixels, coordinates, and - PowerPoint PPT Presentation

Program Realisation 2 Today’s Topics • Pixels, coordinates, and rectangles in Delphi http://www.win.tue.nl/˜hemerik/2IP20/ • Event mechanism in Delphi Lecture 9 Kees Hemerik • Memory leaks, dangling references Tom Verhoe ff • UML: Unified Modeling Language Technische Universiteit Eindhoven Faculteit Wiskunde en Informatica Software Engineering & Technology • (Automated unit testing) Feedback to T.Verhoeff@TUE.NL • Conclusion � 2006, T. Verhoe ff @ TUE.NL c 1 Program Realization 2: Lecture 9 � 2006, T. Verhoe ff @ TUE.NL c 2 Program Realization 2: Lecture 9 Pixels and coordinates Rectangles x=0 1 2 3 x=0 1 2 3 4 • FillRect(XL, YL, XH, YH) colors the points x, y such that y=0 y=0 1 XL ≤ x < XH ∧ YL ≤ y < YH 1 2 2 • It has width XH - XL and height YH - YL 3 • FillRect(X0, YL, X1, YH) and FillRect(X1, YL, X2, YH) are horizon- tally adjacent: they touch, but do not overlap • Pixels are not points, but little squares • FillRect(X, YL, X, YH) is empty • Coordinate options: through pixel centers , between pixels • Scales well: FillRect(0, 0, XH, YH) vs. FillRect(0, 0, 2*XH, 2*YH) • Edsger W. Dijkstra. Why numbering should start at zero . EWD 831, • For many purposes, coordinates between pixels are preferred Aug. 1982 � 2006, T. Verhoe ff @ TUE.NL c 3 Program Realization 2: Lecture 9 � 2006, T. Verhoe ff @ TUE.NL c 4 Program Realization 2: Lecture 9

Framed Rectangles Event Mechanism in Delphi: Main Event Loop x=0 1 2 3 4 5 6 7 1 program PrDirTreeView; y=0 2 1 3 uses 2 4 Forms, 5 Main in ’Main.pas’ {Form1} ; 3 6 4 7 begin 8 Application.Initialize; 9 Application.CreateForm(TForm1, Form1); 10 Application.Run; • Rectangle(0, 0, 5, 4) ; Rectangle(4, 0, 7, 4) 11 end . • These share a 1-pixel boundary, or each has 0.5-pixel boundary Application.Run starts the main event loop • In final assignment, we want Rectangle(0.5, 0.5, 4.5, 3.5) and The main event loop waits for an event and calls its event handler Rectangle(4.5, 0.5, 6.5, 3.5) � 2006, T. Verhoe ff @ TUE.NL c 5 Program Realization 2: Lecture 9 � 2006, T. Verhoe ff @ TUE.NL c 6 Program Realization 2: Lecture 9 Event Mechanism in Delphi: Event Memory Leaks and Dangling References Memory leak : after p := q or New(p) or p := ...Create(...) , (old p)ˆ • Events are triggered by user actions and object state changes is possibly still allocated but unreachable • Events are implemented as private fields with method pointers , • The amount of usable memory has diminished (leaked away) e.g. of type TNotifyEvent • GetHeapStatus reports some memory statistics (e.g. TotalAllocated ) • TNotifyEvent = procedure (Sender: TObject) of object ; Dangling references : after Dispose(p) or p.Free , other references could still point to (old p)ˆ • Procedure types • References to disposed/freed objects are called ‘dangling’ • Cannot be accommodated in the static call graph • The objects pointed to are no longer valid and are unreliable � 2006, T. Verhoe ff @ TUE.NL c 7 Program Realization 2: Lecture 9 � 2006, T. Verhoe ff @ TUE.NL c 8 Program Realization 2: Lecture 9

Memory Leaks and Dangling References: Examples UML: Unified Modeling Language See final assignment, Main.pas : • Standard graphical language for modeling object-oriented software 1 // invariants --------------------------------------------------------- ... 2 • Syntax: Diagrams, but also textual representation (OCL) 3 // I2: (FFocus = nil) or (FFocus is a node in the tree with root FRoot) 4 ... 5 procedure TForm1.ChangeRoot(APath: String ); • Semantics: somewhat controversial 6 begin 7 FFocus := nil ; 8 FRoot.Free; 9 FRoot := MakeDirTree(APath); • For (static) structure and (dynamic) behavior 10 end ; • Extensible, still evolving Omitting FRoot.Free causes a memory leak after line 9 Omitting FFocus := nil , makes FFocus a dangling reference after line 8 • Not a design method (violating I2 ) � 2006, T. Verhoe ff @ TUE.NL c 9 Program Realization 2: Lecture 9 � 2006, T. Verhoe ff @ TUE.NL c 10 Program Realization 2: Lecture 9 Automated Unit Testing Framework Main Theme: Modular Structure • For each unit U , write a separate unit test driver Test_U • Manage Complexity • Test_U uses U , makes various calls of U , and checks the results • Separation of Concerns • DUnit for Delphi, or FPCUnit for FreePascal/Lazarus • Divide and Conquer • X Unit test framework provides classes for organizing test cases, • Design by Contract and checking and reporting of results � 2006, T. Verhoe ff @ TUE.NL c 11 Program Realization 2: Lecture 9 � 2006, T. Verhoe ff @ TUE.NL c 12 Program Realization 2: Lecture 9

Why Modular Structure? How to Design During design, many decisions must be made • Correct construction Manage complexity Design guidelines, principles, and methods needed • Team construction Reduce development time Modular structure: how to ‘find’ the modules • Verification Errors are inevitable • Top-down design , stepwise refinement, functional decomposition • Adaptation Change is inevitable • Bottom-up design • Reuse Reduce budget Functionality versus data as basis for modularity � 2006, T. Verhoe ff @ TUE.NL c 13 Program Realization 2: Lecture 9 � 2006, T. Verhoe ff @ TUE.NL c 14 Program Realization 2: Lecture 9 Main Themes What Next? • Abstract Data Types and object-oriented programming • Recursion , both in control and in data • 2IA20: Ontwerp van Algoritmen 2 • Event-driven, interactive Graphical User Interfaces • 2IF10: Componenten 1 • Borland Delphi with Object Pascal � 2006, T. Verhoe ff @ TUE.NL c 15 Program Realization 2: Lecture 9 � 2006, T. Verhoe ff @ TUE.NL c 16 Program Realization 2: Lecture 9