Referee Scheduler CIS 758 Blue Elephant n Tony
Referee Scheduler CIS 758 Blue Elephant n. Tony Di. Cola n. Mauktik Gandhi n. Jeff Mathew n. Tim Mc. Connell n. Todd Sahl n. Eugene Talagrand
Presentation Outline n n n Product Demonstration / Overview Functional Requirements Intro Non-Functional Requirements Intro Process Intro Non-Functional Requirements in Detail ¡ Traceability through Design, Arch. , Impl.
Product Demo n Let’s check it out
Requirements Overview C Core Functionality S Security U Usability S Supportability P Performance Functional Requirements Non-Functional Requirements
Core Functionality n S Main Use Case ¡ n C Allowing Referees to Schedule Online Main Additional Functional Req. ¡ Security – No Unauthorized Browsing C S U S P
Core Non-Functional Reqs n P Easy to Learn to Use Supportability ¡ n S Usability ¡ n U Easy to Learn to Program Performance ¡ Speedy Enough Under Concurrent Load
Process Intro n Lightweight RUP, ala Craig Larman ¡ ¡ Step-by-Step OOAD Inception, Elaboration n n New Methodology, Martin Fowler ¡ n n Bounded Iterations Adaptive, People Oriented Rapid UI Prototyping w/ Feedback T-Model, Middleware Technologies ¡ From J 2 EE Best Practices Article
T Model by Middleware Co.
Metrics? n n n Fowler: Product of Manufacturing Optimization Ramnath: Do It Please Blue Elephant: We Tried ¡ ¡ Timesheets Hard to Keep Up With
Metrics: Results n Anecdotal Results: ¡ Productivity Increased as: n Configuration Management Settled Down ¡ n Initial Problems: n Eclipse n Tomcat n Hibernate, My. SQL n Struts Members Became Familiar with Core Architecture – MVC, Struts, JSP, JSTL
Core Architecture - MVC
MVC Continued
Transactions
Transactions contd.
Concurrency n n Transient vs. Persistent Objects Optimistic Locking ¡ ¡ Built in Support in Hibernate Finer Grain Control Available with Custom Code
Security - Requirements n Access to registered users only ¡ n Access control and Roles ¡ n Prevent public browsing Referees vs. Administrators Password Security ¡ ¡ Encrypted passwords in database Email notification when password changes C S U S P
Security - Architecture n User class hierarchy ¡ ¡ Hibernate mapping Access Control Filter Logical Paths Tomcat Roles ? C S U S P
Security - Architecture n Password Service ¡ ¡ n SHA 1 – One-way encryption function Random password Generation Email Service ¡ Java Mailing API C S U S P
Usability - Requirements n n No End User Training Possible Successful Adoption Hinges on Transparent Usability End Users are not Computer Experts Accessibility C S U S P
Usability - Design n Transparent Navigation ¡ ¡ Shallow Information Hierarchy Tabbed Interface Clear, Consistent Page Sections Consistent Placement of Feedback C S U S P
Usability – Design Continued n Task Oriented Design ¡ ¡ ¡ n Minimal Text & Images, No ‘Happy Talk’ Built In Help Java. Script Validation of Input Accessibility ¡ ¡ Text-Only Browser Support Minimal Browser Dependency C S U S P
Usability Architecture & Impl. n Common, Ubiquitous Technologies ¡ n Focus on Architecture Extensibility ¡ n Server Pages, Java. Script, CSS Templating, Page Composition Used Standardized Libraries ¡ JSTL - Simpler Language, Easier for Page Designers C S U S P
Usability Process n Iterative Prototype ¡ ¡ ¡ Broad and Shallow Little or No Functionality Feedback From Clients and Users C S U S P
Supportability Requirements n Extensibility ¡ ¡ n Maintainability ¡ n Additional Use Cases to be Implemented Requirements Change Over Time Future Maintenance Programmers Need to Understand Architecture, Code Configurability C S U S P
Supportability Design n Separation of Concerns into Tiers ¡ ¡ ¡ Presentation Layer Workflow Layer Business Delegate Layer Domain Model Layer Data Access Object Layer Data Source Layer C S U S P
Supportability Design Contd. n Separation of Concerns into Tiers ¡ Decoupling of Components of Application n Limits Effect of Change in one area Makes Code Easier to Comprehend Allows Parallel Development via Interfaces C S U S P
Supportability Design Contd. n Documentation of Design ¡ ¡ Short Papers on Technologies / Design Patterns Use Case Diagrams / Sequence Diagrams Pointers to Good Resources Doxygen API Documentation C S U S P
Supportability Architecture n n Strict Adherence to MVC Pattern Use of Popular Frameworks ¡ ¡ n Workflow by Struts Persistence by Hibernate Configurability ¡ ¡ Strategy Patterns Externalized Strings C S U S P
Supportability - Process n Incremental Refactorings ¡ ¡ Refactored Packages Page Composition Externalized Strings Class Based CSS Design C S U S P
Performance - Requirements n n Thousands of Games and Users During Initial Sign-Up Period, Several Hundred Concurrent Users ¡ Site Must Remain Usable and Responsive under Load C S U S P
Performance – Design Cont. n n Presentation Layer: XSL-T was used for the first 4 Weeks ¡ n n Provides Extensibility, but very Computationally Intensive JSP/JSTL Refactoring One Week of Performance Testing C S U S P
Performance – Design Cont. n Keeping Games in Memory ¡ n Client Side Sorting, Filtering of Conflicting Games Offloaded to User to Reduce Server Load ¡ n Required 300 MB of RAM for 300 users Optimized Primary Database Query Trade-off between memory, CPU and Database performance C S U S P
Performance - Process n n Speed of Main Use Case always considered Refactored Session cache design C S U S P
- Slides: 33