18-841/17-654 Team 2 Project Page


Team 2 Project Page 17-654: Analysis of Software Artifacts 18-841: Dependability Analysis of Middleware

Team Members:

Matt Bass mtb@sei.cmu.edu
Manny Bhojwani manikbhojwani@hotmail.com
Paulo Merson pfm@sei.cmu.edu
Vijay Vadlamudi vsai@sei.cmu.edu

Project Title:

Airline Reservation System

Application Description:

A fault tolerant, high performance, real-time airline reservation system that allows users to query flight information for seat availability, make and cancel reservations, and pay for reservations.

Index:

Task Allocation
Platform and Technology
Requirements

Baseline Application Features and use cases

Reliability Requirements

Real-Time Requirements

Performance Requirements

Architecture

Runtime View
Deployment View
Mapping

Design

Database Tables
Statechart diagram
Fault-recovery sequence diagram

Interfaces
Install and deploy
Test Scripts
Performance Analysis - Phase I

Next Improvements - Phases II and III

TO DO List

Task Allocation


Task	Manny	Matt	Paulo	Vijay
Environment setup - application server	X		X
Environment setup - database sever		X
Requirements documentation: use cases diagrams and prose				X
Architecture (network view, runtime view, code view)	X	X	X
Data model: conceptual model and physical model (tables, views, etc.)				X
Coding - server-side Java components	X	X	X
Coding - client-side GUI interface (Java Swing)	X		X
Testing functionality (QA)				X
Performance analysis		X		X
Real-time analysis		X		X
Reliability analysis			X	X
Presentation	X	X	X	X

Platform and Technology

J2EE v1.3 (Java 1.3.1)
Application server: BEA WebLogic 7.0 on Windows 2000
Database server: MS SQL Server 7.0 on Windows 2000

Requirements

Baseline Application Features

A user may obtain available seating information for flight between specified locations, for a given date.
A user may make a reservation for any available seat(s).
A user may cancel an existing reservation.
A user may pay for a reservation by providing credit card to the system.

The system functionality is described in more detail using UML use cases.

Reliability Requirements

A client failure, on any transaction step, causes the whole transaction to be lost.
A client, or a transaction, is unaffected by a single server or a single database failure.
The system is available 24x7.
A network failure of 2 seconds, or less, causes no transactions to be lost.
A network failure of more than 2 seconds causes potentially all transactions to be lost.

Real-Time Requirements

Any reservation transaction step completes in 3 seconds.

Performance Requirements

The system can process 100 transactions per second under normal conditions.
The system can process 75 transactions per second in the worst case.
The system can support 20 concurrent users.
Reservations can be made up to 6 months from the current date
Up to 10 flights a day may be scheduled with up to 150 seats per flight.

Architecture

The architecture is represented using two different views. The runtime view shows the application components to be built and how they interact at runtime, and the deployment view depicts the machines and network connections of the production environment.

Runtime View

The first diagram represents the normal operation of the system. At runtime there are:

One or more instances of the client component (clientArs)
One or more instances of the application server (WebLogic).
One or more instances of the RestartServer application - one instance running on each machine where the application server runs.
Just one instance of "God", which is the naming service and the replication manager.
Just one instance of the database.
Just one instance of Credit Card "external" application and respective database.

The second diagram is slightly different from the previous one. It shows the WorkloadTest application as the client. This program provides synthetic workload for performance tests. Also, "God" is modified to act as a fault injector. Thus, the WorkloadTest will call God to schedule shutdown of the servers after a period of time and then will run N iterations of a loop where it calls the business methods. After the specified scheduled period, God will shut down each registered server, one after the other with regular intervals.
The activations that are specific for fault injection are in red.
images/runtimeViewFI.jpg

Deployment View

Mapping


Runtime Component	Deployment View Component
clientArs	User machine
Search	App. Server 1, App Server 2 (WebLogic 7.0)
ReserveAndBuy	App. Server 1, App Server 2 (WebLogic 7.0)
Authenticate	App. Server 1, App Server 2 (WebLogic 7.0)
ArsStartup	App. Server 1, App Server 2 (WebLogic 7.0)
LocalRestart	App. Server 1, App Server 2 (WebLogic 7.0)
ARS Database	DB Server (MS SQL Server)
CreditCard Database	DB Server (MS SQL Server)
CreditCard	Naming server & Replication mgr
God	Naming server & Replication mgr

Design

This section is not intended to show the complete detailed design of the system, but just a few diagrams that are useful in understanding the software implementation. That includes the database model and a UML statechart diagram showing the states of a purchase.

Database Tables

Statechart Diagram

Fault-recovery Sequence Diagram

Interfaces

The server-side components of the system are EJBs that expose a set of business methods. The interfaces are documented using javadoc.

Team 2 Project Page

Team Members:

Project Title:

Application Description:

Index:

Task Allocation

Task

Manny

Matt

Paulo

Vijay

Platform and Technology

Requirements

Baseline Application Features

Reliability Requirements

Real-Time Requirements

Performance Requirements

Architecture

Runtime View

Deployment View

Mapping

Design

Database Tables

Statechart Diagram

Fault-recovery Sequence Diagram

Interfaces

Fault-Tolerant Baseline Application

Scenarios/Interactions

Current Status

Downloads

Real-Time Fault-Tolerant Baseline Application

Scenarios/Interactions

Current Status

Downloads

High-Performance Real-Time Fault-Tolerant Baseline Application

Scenarios/Interactions

Current Status

Downloads