Project: Rooms And
Colloquium System
ROOMS Team
CS706, Analysis of Software Artifacts
Fall 2001
Current Rooms System
Problem Statement
Replace current room reservation
system
•
/
additional functionality
/
better documentation
/
better extensibility
/
better integration with colloq
Process
Requirements
Use Cases
Program Design
System Design
Implementation
Testing
Requirements
Requirements
Requirements
Requirements
Will
Benton
Requirements
Requirements
Will
Benton
Gerry
Tutsch
Requirements
Requirements
Will
Benton
Gerry
Tutsch
Dave
Parter
Requirements
Faculty
Requirements
Will
Benton
Gerry
Tutsch
Dave
Parter
Requirements
Current
Users
Faculty
Requirements
Will
Benton
Gerry
Tutsch
Dave
Parter
Requirements
Marv
Solomon
Current
Users
Faculty
Requirements
Will
Benton
Gerry
Tutsch
Dave
Parter
Use Cases
Use Case, for a User
High Level Design
High Level Design
User
High Level Design
Client
User
High Level Design
Client
User
Server
High Level Design
Client
User
Server
Persistence
High Level Design
Client
User
Server
Persistence
Software Targets
Tomcat
/
/
Java
/
/
Servlet API
/
JSSE
/
JavaMail
/
JAF
PostgreSQL
Refining Design
Browser
User
Servlet
PostgreSQL
Refining Design
Browser
Servlet
PostgreSQL
User
HTTP
or
HTTPS
JDBC
Components
Focusing
Browser
Servlet
PostgreSQL
User
HTTP
or
HTTPS
JDBC
Refining
Servlet
request
HTTP
response
Rooms
Servlet
Handler
JDBC
Refining
request
HTTP
response
Rooms
Servlet
Handler
HTML
Form
Web
Page
JDBC
Sequence
Refining
Handler
Factory
request
HTTP
response
Rooms
Servlet
Handler
HTML
Form
Web
Page
JDBC
Refining
Handler
Factory
request
HTTP
response
Rooms
Servlet
Handler
HTML
Form
Web
Page
JDBC
Refining
Handler
Factory
request
HTTP
response
Rooms
Servlet
Handler
HTML
Form
Web
Page
JDBC
Refining
<<abstract>>
HTMLForm
request
HTTP
response
Rooms
Servlet
<<concrete>>
Handler
<<concrete>>
HTMLForm
<<concrete>>
WebPage
JDBC
From Design to Implementation
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…)
Program Design
/
EventHandler (make SQL, deliver SQL
result):
1. Reserve Handler
2. Room Handler
3. User Handler
4. Colloquium Handler
Program Design
Class interaction
Interface
(HTML)
request
Servlet
Event
Handler
SQL
Database
Sequence Diagram
Actor: Visitor / Account User / Administrator
Objects:
/
HTML
/
Servlet
/
EventHandler
/
Database
Example: (add a room available for
reservation):
Sequence Diagram
Expansion of Design
One specific Handler for one specific
Event!
Example:
/
RoomHandler broken into:
/
viewRoomHandler,
/
addRoomHandler,
/
deleteRoomHandler,
/
…
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).
Difference from Design
— remove old reservation
records
Design
Implement
ReservHandler
DelOldReservHandler
no generator of
DelOldReservWebpage
response Webpage
no generator of
(generate response)
HTMLForm
Handler
(to generate Handler)
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!
Walkthrough
“Make Reservation”
“We need this thing to
make a reservation.”
“Got it.”
Talking with Customer
“Make Reservation” in
Requirements Doc
“Make Reservation” in Use
Case Document
“Make Reservation” in Use
Case Diagram
“Make Reservation” in
Logical Class Diagram
“Make Reservation” in DB
Schema
“Make Reservation”
Sequence Diagram
“Make Reservation” Class
API
“Make Reservation” in
Help Manual
Test Plan
Test Plan
Unit Testing
Unit Testing
• The system component functions properly.
• The component’s design requirement is satisfied.
• Unit testing is implemented by code writers.
Test Plan
Unit Testing
Code Review
Code Review
/
Code Walkthrough
/
/
Code Inspection
/
/
Review the code and accompanying
documentation
Review code’s correctness, efficiency,
performance
Code Walkthrough is implemented in the Room
Reservation System
Test Plan
Unit Testing
Code Review
Integration Testing
Integration Testing
/
Verify the system components work together
properly
Tester
Use Case Code Writer
Integration
Leader
Test Plan
Unit Testing
Code Review
Integration Testing
System Testing
Test Plan
Unit Testing
Code Review
Integration Testing
Function Testing
Acceptance Testing
Performance Testing
Interface Testing
System Testing
System Testing
/
Function testing
/
/
Performance testing
/
/
the system performs its functions as specified in
the requirement
security, accuracy, speed and reliability
Acceptance testing
/
the system requested by customers is the
system that was built
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
Integration and System Testing:
Make A Non-Recurring
Reservation
2. Sequence diagram and use case
Sequence Diagram
Use Case
MakeNonRecurReservation
Reserve a room
Room Reservation System Testing Report Form
Tester Name: Ming Li
Testing 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:
The Product
Client (basic)
Client (graphical)
Summary, Stories and
Demo
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)
Thank you!
The Rooms Team would like to
thank:
/
/
Somesh Jha
/
Will Benton
/
Jerry Tutsch
/
Marvin Solomon
/
David Parter
/
Everyone who gave input!