1. Project: Rooms And Colloquium System ROOMS Team CS706, Analysis of Software Artifacts Fall 2001

2. Current Rooms System

3. Problem Statement Replace current room reservation system  additional functionality  better documentation  better extensibility  better integration with colloq

4. Process Requirements Implementation System Design Use Cases Program Design Testing

5. Requirements

6. Will Benton

7. Requirements Will Benton Gerry Tutsch

8. Requirements Will Benton Gerry Tutsch Dave Parter

9. Requirements Will Benton Gerry Tutsch Dave Parter Faculty

10. Requirements Will Benton Gerry Tutsch Dave Parter Faculty Current Users

11. Requirements Will Benton Gerry Tutsch Dave Parter Faculty Current Users Marv Solomon

12. Use Cases

13. Use Case, for a User

14. High Level Design

15. User

16. High Level Design Client User

17. High Level Design ClientServer User

18. High Level Design ClientServerPersistence User

19. High Level Design ClientServerPersistence User

20. Software Targets  Tomcat  Servlet API  Java  JSSE  JavaMail  JAF  PostgreSQL

21. Refining Design Browser Servlet PostgreSQL User

22. Refining Design Browser Servlet PostgreSQL User JDBC HTTP or HTTPS

23. Components

24. Focusing Browser Servlet PostgreSQL User JDBC HTTP or HTTPS

25. Refining Servlet Rooms Servlet Handler response request JDBCHTTP

26. Refining Rooms Servlet Handler response request JDBCHTTP Web Page HTML Form

27. Sequence

28. Refining Rooms Servlet Handler response request JDBCHTTP Web Page HTML Form Handler Factory

29. Refining Rooms Servlet Handler response request JDBCHTTP Web Page HTML Form Handler Factory >

30. Refining Rooms Servlet Handler response request JDBCHTTP Web Page HTML Form Handler Factory >

31. Refining Rooms Servlet > Handler response request JDBCHTTP > WebPage > HTMLForm > HTMLForm >

32. From Design to Implementation

33. Program Design Event  EventHandler  Database Event: 1. Related to Reservation (view, make, cancel, delete…) 2. Related to Room (view, add, delete,edit…) 3. Related to User(add, delete, change privilege…) 4. Related to Colloquium(add, delete, edit…)

34. Program Design  EventHandler (make SQL, deliver SQL result): 1. Reserve Handler 2. Room Handler 3. User Handler 4. Colloquium Handler

35. Program Design Class interaction Interface (HTML) Servlet Event Handler Database request SQL

37. Sequence Diagram Actor: Visitor / Account User / Administrator Objects:  HTML  Servlet  EventHandler  Database Example: (add a room available for reservation):

38. Sequence Diagram

39. Expansion of Design One specific Handler for one specific Event! Example:  RoomHandler broken into:  viewRoomHandler,  addRoomHandler,  deleteRoomHandler,  …

40. Why so many handlers?  Better to implement: Each handler processes specific request, generate specific response web-page.  Better to distribute implementation tasks.  Redundancy? — Just repeat of some headers, the functional part is different for different handlers (no repeat).

42. Difference from Design — remove old reservation records Design Implement ReservHandler DelOldReservHandler no generator of response Webpage DelOldReservWebpage (generate response) no generator of Handler HTMLForm (to generate Handler)

44. Implementation Observations  Diagrams in design phase can not predict the exact number of classes, objects used in implementation.  BUT really make clear the logics of the project (logic components, interactions).  Really helps in implementation!

45. Walkthrough “Make Reservation”

46. “We need this thing to make a reservation.” Talking with Customer “Got it.”

47. “Make Reservation” in Requirements Doc

48. “Make Reservation” in Use Case Document

49. “Make Reservation” in Use Case Diagram

50. “Make Reservation” in Logical Class Diagram

51. “Make Reservation” in DB Schema

52. “Make Reservation” Sequence Diagram

53. “Make Reservation” Class API

54. “Make Reservation” in Help Manual

55. Test Plan

56. Unit Testing Test Plan

57. The system component functions properly. The component’s design requirement is satisfied. Unit testing is implemented by code writers. Unit Testing

58. Test Plan Unit Testing Code Review

59.  Code Walkthrough / Review the code and accompanying documentation  Code Inspection / Review code’s correctness, efficiency, performance / Code Walkthrough is implemented in the Room Reservation System

60. Test Plan Unit Testing Integration Testing Code Review

61. Integration Testing  Verify the system components work together properly Tester Integration Leader Use Case Code Writer

62. Test Plan Unit Testing Integration Testing Code Review System Testing

63. Test Plan Unit Testing Integration Testing Code Review Function Testing Performance Testing Interface Testing System Testing Acceptance Testing

64. System Testing  Function testing  the system performs its functions as specified in the requirement  Performance testing  security, accuracy, speed and reliability / Acceptance testing / the system requested by customers is the system that was built

65. Integration and System Testing: Make A Non-Recurring Reservation 1. Requirement A User can reserve a given room for a specified time range. Each reservation must be associated with a contact person. Each reservation has a purpose (a brief piece of text). User: Account User

66. Sequence DiagramUse Case MakeNonRecurReservationReserve a room Integration and System Testing: Make A Non-Recurring Reservation 2. Sequence diagram and use case

67. Room Reservation System Testing Report Form Tester Name: Ming LiTesting Date: 12/10/01 Name of the Module: Make a NonRecurring Reservation Function of the Module: an account user makes a non recurring reservation Testing Procedure: Click the link for “Create Reservation” and fill in the form, and click the submit button Input Data: mingl(username), ROOMS meeting(event), CS2310(room), 12/10/2001(date), 12:00(start time), 13:00(end time) Output: Schedule table of that date, a color bar with a link to that reservation Test Result: correct function Security Checking: Ok, you must at least be a user to make a reservation Performance Evaluation: OK. The start time only have :00, :15, :30, :45 choices. User Interface Evaluation: OK. However, if there is too many different event description, there will be too many color bar links and they will make the output messy. Does this module implement the requirements?(please underline one) Yes No If no, your comments:

68. The Product

69. Client (basic)

70. Client (graphical)

71. Summary, Stories and Demo

72. People Class Professor Somesh Jha (jha@cs.wisc.edu) Group Mentors Will Benton (willb@cs.wisc.edu), Jerry Tutsch (tutsch@execpc.com) Group Members Brian Bowers (blbowers@cs.wisc.edu), Andrew Palmer (palmeran@biostat.wisc.edu), Hongwei Zhu (hzhu@cs.wisc.edu), Ming Li (mingl@cs.wisc.edu), Minyi Xu (minyi@cs.wisc.edu), Naijun Zhou (naijun@cs.wisc.edu), Keith Noto (noto@cs.wisc.edu)

73. Thank you!  The Rooms Team would like to thank:  Somesh Jha  Will Benton  Jerry Tutsch  Marvin Solomon  David Parter  Everyone who gave input!