Project: Rooms And Colloquium System

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 Use Cases Program Design System Design Implementation Testing

5. Requirements Requirements

6. Requirements Requirements Will Benton

7. Requirements Requirements Gerry Tutsch Will Benton

8. Requirements Requirements Will Benton Gerry Tutsch Dave Parter

9. Requirements Faculty Requirements Gerry Tutsch Dave Parter Will Benton

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

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

12. Use Cases

13. Use Case, for a User

14. High Level Design

15. High Level Design User

16. High Level Design Client User

17. High Level Design Client Server User

18. High Level Design Client Server Persistence User

19. High Level Design Client Server Persistence 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 HTTP or HTTPS JDBC

23. Components

24. Focusing Browser Servlet PostgreSQL User HTTP or HTTPS JDBC

25. Refining Servlet request Handler Rooms Servlet HTTP JDBC response

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

27. Sequence

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

29. Refining Handler Factory <<create>> request Handler Rooms Servlet HTTP JDBC response HTML Form Web Page

30. Refining Handler Factory <<create>> request Handler Rooms Servlet HTTP JDBC response HTML Form Web Page

31. Refining <<abstract>> HTMLForm <<create>> request Rooms Servlet <<concrete>> Handler HTTP JDBC response <<concrete>> HTMLForm <<concrete>> WebPage

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 SQL request Interface (HTML) Servlet Event Handler Database

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

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. “Got it.” “We need this thing to make a reservation.” Talking with Customer

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