Ambulance Dispatch System (CAD System)

Object Design Document

Faisal Azizullah

Brandon Bass

Ali Hashi

Sonali Jejurkar(Team Lead for del-3)

Sirisha Koneru

Ananthapriya Mummineni (Team Lead for del-2)

Shveta Mupparapu (Team Lead for del-1)

Vidya Perumal(Team Lead for del-4)

Group URL:

1.Object Design

1.1.Introduction

1.1.1.Object Design Trade-offs

  • Throughput vs. Latency :

Our project uses event based-control flow i.e. Web server allocates a new thread for each request thereby allowing parallel handling of requests. This increases the throughput but checking overhead slows down.

  • Memory space vs. Response time :

Since our project CAD systemfocuses on providing fastest ambulance service to the victims of any emergency incidents, response time is the most important factor and so more memory can be expended to speed up the software (e.g., caching, more redundancy, etc.)

  • Functionality vs. Usability :

Our software incorporates functionalities which meets the requirement specification. With SQL server as database component, J2EE as business object and JSP as front-end the usability of the CAD system is fully achieved.

  • Efficiency vs. Portability

The system is efficiently designed by which porting from one environment to another is made easy. With Java and flat file tools, portability is much easier to support in various environment.

  • Rapid development vs. Functionality

Traditionally the rapid application development (RAD) approach involves compromises in usability, features, and/or execution speed. Our system is designed to meet the functional specification with rapid application development approach.

  • Cost vs. Reusability

Our software interfaces & components can be reused within the system to implement the functionality for other modules but the software is designed using Java for business logic & SQL Server for data access which is quite expensive compare to other data access tools.

1.1.2.Interface documentation guidelines

  • Classes are named with singular nouns.
  • Methods are named with verb phrases, fields, and parameters with noun phrases.
  • Error status is returned via an exception, not a return value.
  • Definitions, acronyms, and abbreviations
  • CAD (Computer Aided Dispatcher):This is the name given to the software system under consideration.
  • Dispatcher Interface: The Dispatcher gets the details like address of the incident, number of people injured, number of ambulances required and type of emergency from the caller through this dispatcher interface.
  • Ambulance Interface:The CAD system forwards the incident details to the ambulance station via ambulance interface.
  • References
  • Problem Statement:
  • Object Design Template: muenchen.de/twiki/bin/view/OOSE/ObjectDesignDocumentTemplate
  • Object-Oriented Software Engineering- Using UML, Patterns, and Java 2nd Edition
  • Façade Pattern -
  • Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2nd ed., C. Larmann
  • Core J2EE Patterns – Data Access Objects-
  • Design Pattern
  • Facade Pattern

It provides a unified interface to the set of objects in a subsystem. It provides interface to the system. Façade defines a higher level interface that makes a subsystem easier to use.

Facade Pattern Diagram

1.1.5.2.Data Access Objects

A design pattern is a formal way of documenting successful solutions to problems. In our CAD system we use JSP as frontend application, J2EE for business objects and MS SQL server for database to implement our software. The business object uses DAO connectivity to communication with SQL server database. The following diagram explains the whole data objects connectivity with business objects.

  • BusinessObject:

The BusinessObject represents the data client. It is the object that requires access to the data source to obtain and store data. A BusinessObject may be implemented as a session bean, entity bean, or some other Java object, in addition to a servlet or helper bean that accesses the data source.

DataAccessObject:

The DataAccessObject is the primary object of this pattern. The DataAccessObject abstracts the underlying data access implementation for the BusinessObject to enable transparent access to the data source. The BusinessObject also delegates data load and store operations to the DataAccessObject.

DataSource:

This represents a data source implementation. A data source could be a database such as an RDBMS, OODBMS, XML repository, flat file system, and so forth. A data source can also be another system (legacy/mainframe), service (B2B service or credit card bureau), or some kind of repository (LDAP).

TransferObject:

This represents a Transfer Object used as a data carrier. The DataAccessObject may use a Transfer Object to return data to the client. The DataAccessObject may also receive the data from the client in a Transfer Object to update the data in the data source.

1.2.Packages

A package is a grouping mechanism for organizing elements into groups to increase their readability. In other words, it is a grouping of model elements, such as use cases, or activities, defining scopes of understanding. Packages are used to deal with complexity in the same way a user organizes files and subdirectories into directories.

Our CAD system comprises one main package CS6354which in turn has 5 subpackages. Each subsystem is depicted as a package.

1.2.1. Package CS6354:

  • Loginpack:
  • Login
  • LoginEntity
  • Adminpack
  • Admin
  • AdminEntity
  • IncidentInfopack
  • IncidentInfo
  • PatientEntity
  • CADcontrollerpack
  • LocationTrackerpack

Package Diagram

1.3.Class interfaces

Class is a concept that contains attributes and operations. It is an abstraction of a set of objects with the same attributes, operations, relationships and semantics. The classes are represented using MVC (Model/View/Controller) pattern.

1.3.1.Boundary classes:

  • Login:This view class will accept username and password information from the form and set the values into the system using control class called LoginEntity. The control flowsfrom the Login(boundary) to CAD(control) and the association between is one-to-one.
  • IncidentInfo: This view class will accept all the information like name, address, phonenumber, zipcode, ambulance status and patient status from the user interface and set the attribute values into business objects using control class PatientEntity for saving the incident info. The control flow is from the IncidentInfo(boundary) to CAD(control) and the association is one-to-one.
  • Admin: This view class helps creating the users for the CAD system. It includes attributes such as userid, password, name, address, phonenumber, for the given user. It also captures flags whether the user is a manager or admin.This information is stored into the system using control class AdminEntity. The control flow is from theAdmin(boundary) to CAD(control) and the association is one-to-one.
  • LocationTracker: This view class will take the phone number as an input and displays the ambulance status such as where exactly the position of ambulance from the incident site.It will also take callers phone number and return the call location. The control flow is from theLocationtracker(boundary) to CAD(control) and the association is one-to-one.
  • Controller class:

CAD: This controller class performs the following tasks.

  • The login class captures the username and password and validates the values to login into the CAD system.
  • The incidentinfo class captures the incident details and delegates the responsibility to the CAD controller for storing these values into the SQL database.
  • The LocationTracker class captures address, phonenumber, zipcode, Ambulance status and patientstatus parameters into the CAD system to display the Ambulance Status to the user.
  • The admin class captures the userid and password and delegates the responsibility to the CAD for creating a new user.
  • Entity classes:
  • LoginEntity: This model class creates the connection to the database using the datasource and validates the user with the stored password in the database.The control flow is unidirectional ie. from the CAD(control) to LoginEntity(entity) and the association is one-to-many.

  • PatientEntity: This model class creates the connection to the database using the datasource and stores the patient details and incident info into the database.The control flow is unidirectional ie. from the CAD(control) to PatientEntity(entity) and the association is one-to-many.
  • AdminEntity: This model class creates the connection to the database using the datasource and creates a new user into the database.The control flow is unidirectional ie. from the CAD(control) to AdminEntity(entity) and the association is one-to-many.
  • Glossary
  • Class:An abstraction of a set of objects with the same attributes, operations, relationships and semantics.
  • Class Diagram:UML notation representing the structure of the system in terms of objects, classes, attributesoperations and associations. Class diagrams represent object model during development.
  • Inheritance: A feature of object-oriented programming languages by which classes may be specialized from more general superclasses. Attributes and method definitions from superclasses are automatically acquired by the subclasses.
  • Association: A relationship between two or more classes denoting the possible links between instances of the classes. An association has a name and can have multiplicity and role information attached to each of its ends.
  • Multiplicity: A set of integers attached to an association end indicating the number of links that can legitimately originate from an instance of the class at the association end.
  • One-to-one association: An association with multiplicity of 1 on each end.
  • One-to-many association: An association that has a multiplicity of 1 on one end and a 0..n or a 1..n multiplicity on the other end.
  • Many-to-many association: An association with 0..n or 1..n multiplicity on both ends.
  • Precondition: A predicate that must be true before an operation is invoked.
  • Postcondition:A predicate that must be true after an operation is invoked
  • Package: A UML grouping concept denoting that a set of objects or classes are related.
  • Interface:Defines the communication boundary between two entities, such as a piece of software.This separates the methods of external communication from internal operation, and allows it to be internally modified without affecting the way outside entities interact with it, as well as provide multiple abstraction of itself.
  • Design pattern: It describes the problem which occurs over and over again in our environment.Then it describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same twice.
  • façade pattern: It provides a unified interface to a set of objects in a subsystem.Data Access Object(DAO) pattern:separates a data resource's client interface from its data access mechanisms adapts a specific data resource's access API to a generic client interface
  • Model: Represents the persistent information tracked by the system.
  • View: Represents the interaction between the user and the system.
  • Controller: Represents the control tasks performed by the CAD system.