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
Servlet API

/
/ / /

Java
JSSE JavaMail JAF

PostgreSQL

Refining Design

Browser User

Servlet

PostgreSQL

Refining Design

Browser User

Servlet

PostgreSQL

HTTP or HTTPS

JDBC

Components

Focusing

Browser User

Servlet

PostgreSQL

HTTP or HTTPS

JDBC

Refining
Servlet

request HTTP response Rooms Servlet

Handler

JDBC

Refining

request HTTP response

Rooms Servlet
HTML Form

Handler
Web Page

JDBC

Sequence

Refining
Handler Factory request HTTP response Rooms Servlet HTML Form

Handler
Web Page

JDBC

Refining
Handler Factory request HTTP response Rooms Servlet HTML Form

Handler
Web Page

JDBC

Refining
Handler Factory request HTTP response Rooms Servlet HTML Form

Handler
Web Page

JDBC

Refining
<<abstract>> HTMLForm request HTTP response Rooms Servlet <<concrete>> HTMLForm <<concrete>> Handler <<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
no generator of response Webpage no generator of

DelOldReservHandler
DelOldReservWebpage (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 components design requirement is satisfied.

Unit testing is implemented by code writers.

Test Plan
Unit Testing Code Review

Code Review
/

Code Walkthrough
/

Review the code and accompanying documentation

Code Inspection
/

Review codes 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
Integration Leader

Use Case Code Writer

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
/

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

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
MakeNonRecurReservation

Use Case
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!