Object-Oriented Design for Delphi Applications

1. Object-Oriented Design for Delphi Applications Helen Hays, Ph.D. Assoc. Prof. of Computer Science Southeast Missouri State University Cape Girardeau, MO 63701 USA haysh@acm.org

2. Object-Oriented Design forDelphi Applications • Introduction • Description of Project • Design Heuristics • Centralized Design • Distributed Design • Hierarchical Design • Conclusions

3. Introduction • Case study: Delphi used two years with undergraduate software engineering team projects. • Major design constraint encountered: • Delphi requires one main form • Main form automatically activated at beginning • Program is terminated by closing main form. • This paper evaluates three possible designs for the user interface.

4. Three Designs • centralized all intelligence in main form as a Driver • distributed all forms interacting as equals • hierarchical main form as top level, but intelligence distributed

5. Description of the Project • Program for on-line administration of questionnaires with multiple choice answers • Input and validate user ID • Input user information • Display instructions and questions and record choices • Record user comment

6. Main Form for Project

7. Classes Included in Study of Designs for the Interface • FQuest: main questionnaire form • FInitial: initial blank form which displays hourglass cursor while files being loaded • FTitle: replaces initial form and displays title • FID: form to accept/reject user ID • UID : application user ID class • FInvalid : dialigue box informing of invalid ID • FInfo: form to input user information • UTitle: application Title class • FFinal: replaces main form for final • instructions/options • FComment : inputs user comment

8. Six Design Heuristics (Riel)used to evaluate three designs 1. Avoid circular relationships. 2. Encapsulate data and behavior. 3. Distribute system intelligence uniformly. 4. Do not create a “god” class (driver). 5. Keep interface and application separate. 6. Minimize class collaborations.

9. Centralized Design • FQuest is a “driver” class • All intelligence placed in FQuest • All data resides in FQuest (underlying application classes are instantiated there)

10. Centralized Client-Object Chart FQuest FInfo FTitle FID UID FInitial FFinal FInvalid UTitle FComnt

11. Centralized Pseudocode for Handling Major Events • Initial activation of FQuest • Show FInitial and load files • Show FTitle, FID and/or FInvalid; input, validate (giving 3 tries), and store ID • If ID invalid, terminate program • Else show FInfo, input and store user info • Finished Button Click in FQuest • Loop to show FFinal or FCmnt until Exit button pressed in FFinal

12. Evaluation of Centralized Fail 1. Avoid circular relationships. Fail 2. Encapsulate data and behavior. Fail 3. Distribute system intelligence Fail 4. Do not create a “god” class (driver). Fail 5. Separate interface and application Fail 6. Minimize class collaborations.

13. Distributed Design • Application ID and Title objects are instantiated in UID and UTitle respectively. • Each form handles its own events. • FInitial is the “main” form; it is activated first and may be closed by FID or FFinal. • Top-level forms appear in sequence and each one activates the next. • FInvalid and FComnt are used by top-level forms.

14. Distributed Client-Object Chart FInitial FID FFinal FTitle FInfo FQuest UID FInvalid FComnt UTitle

15. Distributed Pseudocode for Handling Major Events • OK Button Click in FID • Increment private variable Tries • Set ID in UID • if UID.Valid, show next form FInfo • else if Tries < 3, show FInvalid • else end program by closing FInitial • Finished Button Click in FQuest • Show FFinal • Exit Button Click in FFinal • End program by closing FInitial

16. Evaluation of Distributed Fail 1. Avoid circular relationships. OK 2. Encapsulate data and behavior. OK 3. Distribute system intelligence OK 4. Do not create a “god” class (driver). OK 5. Separate interface and application Fail 6. Minimize class collaborations.

17. Hierarchical Design • FQuest is main form and root of tree. • FQuest hands control as needed to FInitial, FTitle, FID, FInfo, FComnt, and FFinal then closes itself when Exit pressed in FFinal. • Each form handles its own events. • Application ID and Title objects are instantiated in UID and UTitle respectively.

18. HierarchicalClient-Object Chart FQuest FInitial FID FInfo FTitle FFinal FInvalid FComnt UID UTitle

19. Hierarical Pseudocode for Handling Major Events • On Initial activation of FQuest • Pass control to FInitial, then show FTitle and pass control to FID • if FID does not return OK, then close program. • OK Button Click in FID • Increment private variable Tries • Set ID in UID • if UID.Valid, return OK result • else if Tries < 3, show FInvalid • else return Cancel result • Finished Button Click in FQuest • Pass control to FFinal; when it returns, close.

20. Evaluation of Hierarchical OK 1. Avoid circular relationships. OK 2. Encapsulate data and behavior. OK 3. Distribute system intelligence OK 4. Do not create a “god” class (driver). OK 5. Separate interface and application OK 6. Minimize class collaborations.

21. Summary of Ratings forsix Riel Design Heuristics

22. Conclusions • The Delphi constraints of a “main” form work well for a project such as this one with one main form, but may cause unwanted circular dependencies otherwise. • Forcing a structured design, with the main form as a “driver”, results in a needlessly complicated design. • The optimal design is one in which all other forms are subsidiary to the main form, but each handles its own events independently.

23. References Source and executable files for the three designs may be downloaded from www2.semo.edu/jhays/se/oodelphi/iasted97.html • Borland Delphi for Windows, Version 1.0, Computer Software, (Scotts Valley, CA: Borland International Inc., 1995). • A.J. Riel, Object-Oriented Design Heuristics, (Reading, MA: Addison-Wesley Publishing Co. Inc., 1996). • A. Wozniewicz and N. Shammas, Teach Yourself Delphi in 21 Days, (Indianapolis: Sams Publishing, 1995).