Referee Scheduler

1. Referee Scheduler CIS 758 Blue Elephant Tony DiCola Mauktik Gandhi Jeff Mathew Tim McConnell Todd Sahl Eugene Talagrand

2. Presentation Outline • Product Demonstration / Overview • Functional Requirements Intro • Non-Functional Requirements Intro • Process Intro • Non-Functional Requirements in Detail • Traceability through Design, Arch., Impl.

3. Product Demo • Let’s check it out

4. C Core Functionality U Usability P Performance S Security S Supportability Requirements Overview Functional Requirements Non-Functional Requirements

5. Core Functionality C S • Main Use Case • Allowing Referees to Schedule Online • Main Additional Functional Req. • Security – No Unauthorized Browsing C S U S P

6. Core Non-Functional Reqs U S P • Usability • Easy to Learn to Use • Supportability • Easy to Learn to Program • Performance • Speedy Enough Under Concurrent Load

7. Process Intro • Lightweight RUP, ala Craig Larman • Step-by-Step OOAD • Inception, Elaboration • Bounded Iterations • New Methodology, Martin Fowler • Adaptive, People Oriented • Rapid UI Prototyping w/ Feedback • T-Model, Middleware Technologies • From J2EE Best Practices Article

8. T Model by Middleware Co.

9. Metrics? • Fowler: Product of Manufacturing Optimization • Ramnath: Do It Please • Blue Elephant: We Tried • Timesheets • Hard to Keep Up With

10. Metrics: Results • Anecdotal Results: • Productivity Increased as: • Configuration Management Settled Down • Initial Problems: • Eclipse • Tomcat • Hibernate, MySQL • Struts • Members Became Familiar with Core Architecture – MVC, Struts, JSP, JSTL

11. Core Architecture - MVC

12. MVC Continued

13. Transactions

14. Transactions contd.

15. Concurrency • Transient vs. Persistent Objects • Optimistic Locking • Built in Support in Hibernate • Finer Grain Control Available with Custom Code

16. C S U S P Security - Requirements • Access to registered users only • Prevent public browsing • Access control and Roles • Referees vs. Administrators • Password Security • Encrypted passwords in database • Email notification when password changes

17. C S U S P Security - Architecture • User class hierarchy • Hibernate mapping • Access Control Filter • Logical Paths • Tomcat Roles ?

18. C S U S P Security - Architecture • Password Service • SHA1 – One-way encryption function • Random password Generation • Email Service • Java Mailing API

19. C S U S P Usability - Requirements • No End User Training Possible • Successful Adoption Hinges on Transparent Usability • End Users are not Computer Experts • Accessibility

20. C S U S P Usability - Design • Transparent Navigation • Shallow Information Hierarchy • Tabbed Interface • Clear, Consistent Page Sections • Consistent Placement of Feedback

21. C S U S P Usability – Design Continued • Task Oriented Design • Minimal Text & Images, No ‘Happy Talk’ • Built In Help • JavaScript Validation of Input • Accessibility • Text-Only Browser Support • Minimal Browser Dependency

22. C S U S P UsabilityArchitecture & Impl. • Common, Ubiquitous Technologies • Server Pages, JavaScript, CSS • Focus on Architecture Extensibility • Templating, Page Composition • Used Standardized Libraries • JSTL - Simpler Language, Easier for Page Designers

23. C S U S P Usability Process • Iterative Prototype • Broad and Shallow • Little or No Functionality • Feedback From Clients and Users

24. C S U S P Supportability Requirements • Extensibility • Additional Use Cases to be Implemented • Requirements Change Over Time • Maintainability • Future Maintenance Programmers Need to Understand Architecture, Code • Configurability

25. C S U S P Supportability Design • Separation of Concerns into Tiers • Presentation Layer • Workflow Layer • Business Delegate Layer • Domain Model Layer • Data Access Object Layer • Data Source Layer

26. C S U S P Supportability Design Contd. • Separation of Concerns into Tiers • Decoupling of Components of Application • Limits Effect of Change in one area • Makes Code Easier to Comprehend • Allows Parallel Development via Interfaces

27. C S U S P Supportability Design Contd. • Documentation of Design • Short Papers on Technologies / Design Patterns • Use Case Diagrams / Sequence Diagrams • Pointers to Good Resources • Doxygen API Documentation

28. C S U S P Supportability Architecture • Strict Adherence to MVC Pattern • Use of Popular Frameworks • Workflow by Struts • Persistence by Hibernate • Configurability • Strategy Patterns • Externalized Strings

29. C S U S P Supportability - Process • Incremental Refactorings • Refactored Packages • Page Composition • Externalized Strings • Class Based CSS Design

30. C S U S P Performance - Requirements • Thousands of Games and Users • During Initial Sign-Up Period, Several Hundred Concurrent Users • Site Must Remain Usable and Responsive under Load

31. C S U S P Performance – Design Cont. • Presentation Layer: • XSL-T was used for the first 4 Weeks • Provides Extensibility, but very Computationally Intensive • JSP/JSTL Refactoring • One Week of Performance Testing

32. C S U S P Performance – Design Cont. • Keeping Games in Memory • Required 300 MB of RAM for 300 users • Client Side Sorting, Filtering of Conflicting Games Offloaded to User to Reduce Server Load • Optimized Primary Database Query • Trade-off between memory, CPU and Database performance

33. C S U S P Performance - Process • Speed of Main Use Case always considered • Refactored Session cache design