SCE Exit Interview Architecture Document
1.0 Introduction
1.1 Document Conventions:
As of this time there are no project-specific conventions, or terms,
that are introduced in this architectural diagram. This diagram is
explained in the most simplest of terms; each of the terms/functions
labeled in this diagram are self-explanatory.
1.2 Purpose:
The purpose of this document is to demonstrate and convey the
functionality of the new, online SCE Exit Interview Database in its primitive
form – its architecture.
2.0 Description of Architecture
This architectural diagram is a diagram divided into hierarchical sections
(UMKC faculty, administration, and students). In General the architecture
is an n-tiered Architecture. These sections will trace the limits of
utilization for all 3 user classes of the SCE Exit Interview Database:
Administration: Members of the SCE Administration are the most
limited of the 3 user classes, therefore we assume that they will use the
system the least. The only capability administration has of our system will
be to change all user passwords.
Faculty: Members of the SCE Faculty have the most control of the
SCE Exit Interview Database, compared to SCE Administration. These
members are allowed to add and/or delete questions, view student data,
add supplemental comments to survey questions, and verify the
correctness of data.
Students: SCE students qualified to complete the SCE Exit
Interview Survey are the intended users of this system. Students will
complete a new, online version of this survey and submit their data to a
database for SCE departmental analysis and review. Because the exit
interview is now online, students will have the ability to log-on and -off to
the system, and save and resume the survey at their own leisure.
2.1 Justification of Architectural Design
The reason why we chose an n-tiered architecture is because it is very
common in web applications. The n-tiered / layered architecture
promotes high cohesion through the grouping of similar functionality into
various tiers. It also promotes low coupling by its very nature. Each tier is
only coupled to the tier directly above and below it and interfaces or even
Facades can be utilized within each tier to minimize the impact, for a
specific tier, of changes in adjoining tiers.
The implementation of this architecture will provide a modular, reliable,
and stable application that will be easy to maintain and extend.