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

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
c
<<
a
re

Handler
Factory

te
>>

request
HTTP
response

Rooms
Servlet

Handler

HTML
Form

Web
Page

JDBC

Refining
c
<<
a
re

Handler
Factory

te
>>

request
HTTP
response

Rooms
Servlet

Handler

HTML
Form

Web
Page

JDBC

Refining
c
<<
a
re

<<abstract>>
HTMLForm

te
>>

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
response Webpage

DelOldReservWebpage
(generate response)

no generator of
Handler

HTMLForm
(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

Code Inspection

Review the code and accompanying documentation

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

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!