Team Rain Delay
Emergency Services Directory
Software Architecture Document
Version 1.2
Emergency Services Directory
Software Architecture Document
Version:
1.1
Date: 19/May/08
Revision History
Date
Version
Description
Author
1.0
Initial Version
19/May/08
1.1
Filled in All Missing Sections
TJ Wasik
20/May/08
1.2
Added reference to the template for this
document
TJ Wasik
Added comments on architecture section
Table of Contents
1.
Introduction ..................................................................................................................................................... 4
1.1
1.2
1.3
1.4
Purpose
Scope
References
Overview
4
4
4
4
2.
Architectural Representation ........................................................................................................................... 4
3.
Architectural Goals and Constraints ................................................................................................................ 4
4.
Logical View ................................................................................................................................................... 5
4.1
4.2
5.
Overview
Architecturally Significant Design Packages
4.2.1 Application Layer ......................................................................... 5
1.1.2 Data Layer ..................................................................................... 6
4.2.2 Presentation Layer......................................................................... 6
5
5
Deployment View ........................................................................................................................................... 6
6.
Implementation View ...................................................................................................................................... 7
6.1
6.2
Overview
Layers
1.1.3 Presentation Layer......................................................................... 7
1.1.4 Web Services Layer ...................................................................... 7
1.1.5 Data Layer ..................................................................................... 8
7
7
7.
Data View (optional) ....................................................................................................................................... 8
8.
Size and Performance ...................................................................................................................................... 9
9. Comments on Architecture.9Software Architecture Documen
1.
Introduction
1.1
Purpose
This document provides a comprehensive architectural overview of the system, using a number of different
architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.
Emergency Services Directory
Software Architecture Document
Version:
1.1
Date: 19/May/08
1.2
Scope
This document applies to the overall design of the system. It contains information relating to the architectural design of the software, the Structure of the Database, and of the physical servers hosting the site.
1.3
References
The template for this document:
http://web.cs.wpi.edu/~gpollice/cs4233-a05/rup_sad.html
1.4
Overview
This Document provides the reader with a deeper understanding of the design of the Emergency Services
Directory Website. It is organized into several views of the system, the Logical view, which will give an
overview of the subsystems and components the system is comprised of, the Deployment view, which will
give go into how the system has been deployed and what it's being hosted on, the Implementation view,
which will show how the system has been implemented and go into more detail about the different parts of
the system, and the Data view which will show how the database is structured and organized.
2.
Architectural Representation
This system was designed using a standard three tiered architecture, with a Presentation Tier, Application
Tier and Data tier. The Presentation Tier contains all of the visible web pages and handles all input from
and output to the user. The Application Tier handles all of the Business logic and provides an abstraction to
the database, the Data tier consists of the Database and stored procedures contained within, this provides
the persistence required for the system. The Logical View shows a quick overview of all of the basic subsystems in the System and gives a basic overview of the System as a whole. The Deployment view tells
how the system is physically configured. The Implementation View gives a more in-depth view into how
the system has been implemented. The Data view shows how the Database is setup and structured.
3.
Architectural Goals and Constraints
The previous two teams had done a considerable amount of the design work. As a result, we were required
to use the existing architecture. We didn’t have much time for any re-factoring work and decided instead to
focus on the addition of new features, such as more accessible and easier to use searching and Google Maps
mashup.
Emergency Services Directory
Software Architecture Document
4.
Logical View
4.1
Overview
Version:
1.1
Date: 19/May/08
SurveySystem
AdvertisementSystem
«subsystem»
STEPEMS
PrintDirectory
AddressCorrectionSystem
Registration
*
*
WebServices
BusinessObjects
DataAcessObjects
*
Database
*
StoredProcedures
This Diagram shows the various high level packages that the system is broken down into. The packages can
be seen here separated into the various layers by color, the Presentation layer is the blue and yellow packages, the Application layer is the green and red packages while the Data layer is the grey packages.
4.2
Architecturally Significant Design Packages
4.2.1
Application Layer
The Application Layer provides the business logic and connects the Presentation Layer to the Database.
The Application Layer is contained within the EMSWebServices package. All communication with the
Presentation layer is done through Web Services.
Emergency Services Directory
Software Architecture Document
Version:
1.1
Date: 19/May/08
1.1.1.1 Web Services
This Package contains all of the Web Services that are provided by the application layer and consumed by the presentation layer
1.1.1.2 Business Objects
This package contains all of the objects which provide the Business logic for the system.
1.1.1.3 Data Access Objects(DAO)
This Package contains all of the objects which are used to communicate with the database. Each
object contained in this package has a table or tables representing it in the database.
1.1.2
Data Layer
The Data Layer consists of the MS SQL server 2000 database and the stored proceudres contained within.
The Data Layer provides persistence for the system and all communication is done through SQL queries,
stored procedures and views.
4.2.2
Presentation Layer
The Presentation Layer is composed of two basic packages, Registration and STEPEMS. All front end
components used Active Server Pages as the primary interface.
1.1.2.1 STEPEMS
This package contains almost all of the visible pages and the logic to do basic parsing and validation of data related to the pages directly. An example of some of the Subsystems contained within
STEPEMS are:
1.1.2.1.1
Survey System
This subsystem is responsible for managing survey question and responses.
1.1.2.1.2
Searching
This subsystem is responsible for search queries.
1.1.2.1.3
Advertisement System
This subsystem is responsible for managing the advertisements in the system.
1.1.2.1.4
Print Directory
This subsystem is responsible for generating the Indesign file for the printed directory.
1.1.2.1.5
Address Correction System
This subsystem is responsible for the automatic correction of addresses.
1.1.2.2 Registration
This subsystem contains the components for the registration of new accounts and organizations.
5.
Deployment View
This system is deployed on a single server hosting the database, webserver, and webservices. Clients connect using web browsers through the internet.
Emergency Services Directory
Software Architecture Document
6.
Implementation View
6.1
Overview
Version:
1.1
Date: 19/May/08
The system is implemented using a three tiered architecture. The first layer is the Presentation Layer consisting of Active Server Pages, This layer contains all of the pages that the user sees, and some of the basic
logic to present them and validate input. The second layer is the Web Service layer, this layer provides all
Business Logic functions and connects the Presentation Layer and the Data Layer. The third Layer is the
Data Layer, this layer consists of the Database, and utilizes stored procedures to keep the logic of maintaining the database closer to the data.
6.2
Layers
1.1.3
Presentation Layer
The presentation Layer Consists of the STEPEMS and Registration projects. These projects contain all of
the visible web pages, as well as some of the logic to deal with parsing and verifying user input. The Registration project deals only with the registration of a new user, or organization, and duplicates a lot of the
functionality of the STEPEMS package. Both of these projects communicate with the Web Services layer,
and gain access to persistent data through that layer.
1.1.4
Web Services Layer
The Web Services Layer consists of the EMSWebServices project and provides all of the Business Logic of
the system. This layer also acts as an intermediary between the Data layer and the Presentation layer. This
layer provides Web services which the Presentation layer consumes, and uses SQL queries to communicate
with the data layer
Emergency Services Directory
Software Architecture Document
Version:
1.1
Date: 19/May/08
1.1.5
Data Layer
The Data Layer consists of the MS SQL database and provides persistence for the system as well as the
logic directly related to the manipulation of that data through the means of stored procedures. This layer
communicates with the Web Services Layer by responding to SQL queries.
7.
Data View (optional)
Hospital
PhysicianHospital
Org a n i za ti o n ID
P h y si ci a n ID
S y ste m
Org a n i za ti o n ID
Organization
Org a n i za ti o n ID
Ty p e
Na m e
Be d s
Fire
E DBe d s
Org a n i za ti o n ID
E DDi re cto r
Pager
E DP h o n e
Physician
E DF a x
Account
Acco u n tID
Em a il
P a sswo rd
P h y si ca l Ad d re ss1
Region
P h y si ci a n ID
E DVi si ts
P h y si ca l Ad d re ss2
F i rstNa m e
Ab b re v i a ti o n
Re g i o n ID
P h y si ca l Ci ty
Re g i o n Na m e
Ad d re ss1
Mi d d l e Na m e
Co n tro l P h o n e
Ad d re ss2
F i rstNa m e
L a stNa m e
Resource
P re sNa m e
Phone
Org a n i za ti o n ID
P re sE m a i l
Ca te g o ry
Ho sp Di rNa m e
[L e v e l ]
Ho sp Di rE m a i l
De scri p ti o n
E DMe d Di r
Ad m i n Na m e
E DMe d Di rE m a i l
Ho sp i ta l S e rv i ce ID
Ad m i n Ti tl e
E DDi re cto rE m a i l
Ho sp i ta l S e rv i ce Na m e
E l e ctF i rstNa m e
Ho sp Me d Co o rd Na m e
Ab b re v i a ti o n
E l e ctL a stNa m e
Ho sp Me d Co o rd E m a i l
Ci ty
L a stNa m e
Zip
Phone
Cre a te d
County
Co u n ty ID
Co u n ty ID
Em a il
Co u n ty Na m e
We b si te
L a stL o g i n
HospitalService
Acce ss
S ta te
Phone
Re g i o n ID
Fax
Re g i o n ID
E Ma i l Up d a te s
No te s
Ma n a g e Al l Acco u n ts
Acco u n tID
Ma n a g e P a rtn e rs
Da te Ad d e d
Ap p ro v e Org a n i za ti o n
L a stUp d a te
Ap p ro v e Acco u n t
Ma n a g e L i n k s
AccountRequest
L a stUp d a te Re q u e st
Em a il
F ounded
P a sswo rd
Vi si b l e
Ge n e ra te P ri n t
E xp o rtTo E xce l
ServiceRequest
S e rv i ce Re q u e stID
S e rv i ce Re q u e stNa m e
Org a n i za ti o n Ty p e
HospitalServiceHospital
Ambulance
Ho sp i ta l S e rv i ce ID
Org a n i za ti o n ID
Org a n i za ti o n ID
Pager
F i rstNa m e
Al te rn a te Ad d re ss1
L a stNa m e
Al te rn a te Ad d re ss2
Phone
Al te rn a te Ad d re ss1 1
Org a n i za ti o n Na m e
Al te rn a te Ad d re ss2 2
Co u n ty ID
Al te rn a te Ci ty 1
Re q u e ste d
Al te rn a te Ci ty 2
Are a
Am b u l a n ce S e rv i ce
AmbulanceServiceAmbulance
Am b u l a n ce S e rv i ce ID
Org a n i za ti o n ID
Al te rn a te Co u n ty ID1
Acco u n tID
Al te rn a te Co u n ty ID2
Re q u e ste d
HomeCare
Org a n i za ti o n ID
Al te rn a te Z i p 1
Al te rn a te Z i p 2
Helicopter
Al te rn a te P h o n e 1
Al te rn a te P h o n e 2
Al te rn a te F a x1
MedicalCare
Org a n i za ti o n ID
Am b u l a n ce S e rv i ce ID
Co n ta ct
Am b u l a n ce S e rv i ce Na m e
Are a
Ab b re v i a ti o n
Al te rn a te F a x2
He l i co p te rs
De scri p ti o n
Ho u rs
n u m Ca l l s
n u m Ve h i cl e s
n u m Me m b e rs
sp e ci a l ty Ve h i cl e s
LawEnforcement
Org a n i za ti o n ID
Co n ta ctTi tl e
Co n ta ctNa m e
TTYP h o n e
NursingHome
Org a n i za ti o n ID
Be d s
AmbulanceService
Org a n i za ti o n ID
Emergency Services Directory
Software Architecture Document
Version:
1.1
Date: 19/May/08
This Diagram shows the tables in the database of the system. As can be seen Organization is the primary
table for an entry, each organization also has a sub-type which corresponds with each of the sub-type tables
which are on the right side of the diagram. There are also tables which contain static data, such as counties.
Users are stored in the Account table and are associated with a region.
8.
Size and Performance
This system currently has mostly listings for the finger lakes region, but the editors are attempting to grow
it first to the state level and then eventually to the national level, as such the system had to be designed to
allow it to scale up to significantly larger numbers of users and registered organizations.
1.
Comments on Architecture.
While working with this system we discovered many areas of the architecture that could use improvement,
as such we are recommending that future teams consider a major refactor. The conceptual overview of the
design, as a three tiered architecture is sound, though the implementation of that could use some work. The
main area of focus for a refactor should be the presentation layer, consisting of the STEPEMS and Registration packages. These packages should be combined into one single project, as it is currently these packages have a lot of replicated functionality and create a large amount of complexity by being separate, while
bringing in minimal benefits of this separation. These packages should also be inspected for updateability,
as they currently are a simple, and likely to be performed update such as adding in a new type of organization is a difficult and time consuming task, which involves changing code in many places, a future team
should consider finding a way to make this type of update simpler. There is also some application logic in
this presentation tier that should be moved to the application tier, and some logic is actually split between
the C# back-end and the ASP.net pages, the ASP pages should focus solely on presenting the information,
all logic should be moved to the C# codebehind pages, with it split as it is now understanding how things
work is difficult, and changing them is even worse.
The Application Layer, consisting of the EMSWebServices package is fairly solid. This package is well designed and well implemented, in a refactor this package would require little attention, it will probably require little re-implementation and just some rearranging of where some of the logic is located.
The Data Tier is solid and doesn't require any refactoring, the only changes that are likely to be required to the database are changes that are required to match up with the refactoring of the rest of the system.