1 / 33

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

This presentation provides an overview and demonstration of the Referee Scheduler CIS 758 system, focusing on functional and non-functional requirements, core functionality, usability, performance, security, and supportability. The process intro includes lightweight RUP methodology, step-by-step OOAD, and iterations. Security features user access control, encrypted passwords, and access roles. Usability is client-focused, with transparent navigation, task-oriented design, and minimal browser dependency. Supportability covers extensibility, change management, and maintainability through tier separation and documentation. Performance requirements ensure usability under heavy loads.

davidperry
Télécharger la présentation

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

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related