project 3-i architectural design document · add001 project 3-i architectural design page 6 of 15...

ADD001 Project 3-I Architectural Design

of 15

Project 3-I

Architectural Design Document

Interrogue Polling Company, Inc.

Penn State Harrisburg COMP413W Fall 2007

Version 1.0


of 15

[This page intentionally content-free.]


of 15

Abstract

The Interrogue Polling Company has determined that it is in the interest of the company to automate the core business of opinion survey production. This initiative has been branded, Interrogue Improvement Initiative, or Project-3I. Based on the functional and non-functional requirements put forth in the System Requirements Specification Document, this document establishes the overall architecture and conceptual design upon which the new system will be built.


of 15

Revision History Date Version Description Author

10/15/2007 1.0 Initial version Loretta Euler, CCG Analyst

Approvals

Paul Drake, President, Project Sponsor Date

Prof. J. Lobur, CIO, COMP413W Consulting Group, Inc. Date


of 15

Table of Contents

1.0. Introduction...................................................................................................................................6

1.1. Goals and Objectives ..............................................................................................................6

1.2. Scope of Solution....................................................................................................................6

2.0. Architectural and Component-Level Design.......................................................................7

2.1. Architecture diagram .............................................................................................................7

2.2. Class Design Model for Use Case U1.1 New Survey - TBD .......................................8

2.3. Class Design Model for Use Case U.1.2 Survey Search .............................................8

2.3.1. Updated Use Case Narrative: U.1.2. Survey Search ............................................8

2.3.2. Robustness Diagram: U.1.2. Survey Search ........................................................10

2.3.3. Sequence Diagram: U.1.2. Survey Search.............................................................11

2.3.4. Class Diagram: U.1.2. Survey Search.....................................................................12

2.4. Class Design Model U.1.3. Edit Survey - TBD.............................................................12

2.5. Class Design Model U.1.4. Delete Survey – TBD ........................................................12

2.6. Class Design Model U.1.5. Preview Survey -- TBD ....................................................12

3.0. Quality Assurance .....................................................................................................................13

3.1. Specific test cases .............................................................................................................13

3.1.1. Use Case U.1.2 Survey Search..................................................................................13

Appendix A: Screen Mock Ups ...........................................................................................................14

Use Case U1.2 SURVEYPARAMS Screen Mock Up ............................................................................15

Use Case U1.2 SURVSRCH Screen Mock Up.......................................................................................15


of 15

Project 3-I Architectural Design

1.0. Introduction

This document provides the architectural foundation for the implementation of Project 3-I. The sections that follow describe the overall deployment architecture and preliminary static and dynamic class designs. We also restate and refine the system use cases originally put forth in the System Requirements Specification for this project. Each class design model given below consists of four parts: 1) An updated system use case narrative 2) A robustness diagram 3) A sequence diagram, and 4) A class diagram. The robustness, sequence and class diagrams represent different (graphical perspectives) for that section's updated system use case.

The present work will be used as the basis for the detailed design of the various collaborating classes that will deliver the business functions within the scope of this project.

1.1. Goals and Objectives

The leadership of the Interrogue Polling Company is concerned that the company's lack of a Web presence is causing them to fall behind the competition. In addition to the main goal of moving into Internet space, it is believed that the talents of the staff of Interrogue Polling Company will be more effectively used when automated support is provided to it.

1.2. Scope of Solution

In-scope processes shall be those that lend themselves easily to automation. Ideal automation candidates are those processes that deemed repetitive, have little variation between the different types of surveys, and lend themselves to procedural description by process experts. Out-of-scope processes involve the creative work that is far too complex to automate, such as formulating question phraseology and response metrics. Additional out-of-scope areas are primarily of financial character, such as billing, general accounting, and payroll. The nature of these processes is such that their automation is effectively dealt with by commercial-off-the-shelf (COTS) software.

Project 3-I Scope Summary

In-Scope Processes Out-of-Scope Processes

1. Survey creation Billing 2. Survey execution Accounting & Payroll 3. Survey results compilation

Asset & Facilities Management


of 15

2.0. Architectural and Component-Level Design

The Interrogue survey system will consist of three principal parts:

1. Survey creation

2. Survey execution

3. Survey results compilation

Each of these principal components consists of the functional modules that actually do the work. The detailed use cases for each module were first described by use cases given in the Project 3-I Requirements document, and then elaborated upon as a work product of the current architectural design effort.

2.1. Architecture diagram

The functions of survey creation and survey results compilation will be implemented on a pair of failover-redundant central application servers located in the Interrogue data room. Components for the execution of Web-based surveys will be located on the secure premises of Interrogue's Internet Service Provider. All data collected throughout the daily execution of the Web-based surveys, will be extracted from intermediary databases at the server farm, and transferred asynchronously to the main Interrogue application servers. This data is then the input to the Survey Results Compilation (U3.1) module.

All user-interactive software will execute within standard Web browsers (Mozilla

FireFox and Microsoft Internet Explorer versions 5 and later). The application software will be hosted on a central application server, and the backend database will be MySQL..

Figure 1: Architectural Component Diagram for Project 3-I Deployment


of 15

2.2. Class Design Model for Use Case U1.1 New Survey - TBD

2.2.1. Updated Use Case Narrative - TBD

2.2.2. Robustness Diagram -- TBD

2.2.3. Sequence Diagram—TBD

2.2.4. Class Diagram-- TBD

2.3. Class Design Model for Use Case U.1.2 Survey Search

2.3.1. Updated Use Case Narrative: U.1.2. Survey Search

General Description: Displays the surveys that are active in the system. If the search is invoked from an edit, or delete module, the parameters (search keys) of the survey of interest are returned, otherwise the survey is invoked in "preview" mode. Mock ups of the search screens are provided in Appendix A.

Precondition: Program has been invoked by a calling module, e.g., edit or delete, or has been invoked as a standalone query form the main functional screen. The screen named SURVEYPARAMS is displayed in the user's browser.

Postcondition: The survey keys or an error message have been returned to the calling program. If this module has been called directly, the survey is invoked in "preview" mode (Use Case U.1.5).

Basic Flow U1.2.1 The user enters search parameters in the form of survey

name (keyword) or date range into appropriately labeled fields on the SURVEYPARAMS screen and clicks [Search].

U1.2.2 The system retrieves from the store of surveys a list of survey names, short descriptions, date created, and date last modified where the data values match the search criteria entered on the screen titled SURVSRCH.

U1.2.3 If there are more than 15 surveys, the surveys will be grouped in blocks of 15, with the last block possible containing fewer than 15.

U1.2.4 If there are more than 15 surveys hyperlink to each block of 15 surveys (labeled by "Go to Page:") appears at the bottom of the SURVSRCH screen, along with navigations to first and last pages if there is more than one page. (The user may click on these hyperlinks to navigate through the pages.)

U1.2.5 The system displays each matching survey in columns in the form of survey references that consist of the survey name, its short description, date created, and date last modified. The survey name is rendered as a clickable hyperlink.


of 15

U1.2.6 The user may click on the heading of any column, survey name, its short description, date created, or date last modified to sort by that field.

U1.2.7 The user clicks on a survey name hyperlink to invoke "Preview Survey" (U.1.5).

Alternative Flow:

U1.2.1.a If the ending date of the date range is earlier than the beginning date, or if the dates are not valid (nonblank) dates, the system displays SURVEYPARAMS with the message "Invalid date range." Flow resumes at U1.2.1.

U1.2.2.a The system displays SURVEYPARAMS with the message "No surveys found" when there are no surveys on file that match the search criteria. Flow resumes at U1.2.1.

U1.2.7.b The user may click the [Back] button or close the browser to terminate the search at any time.


of 15

2.3.2. Robustness Diagram: U.1.2. Survey Search


of 15

2.3.3. Sequence Diagram: U.1.2. Survey Search


of 15

2.3.4. Class Diagram: U.1.2. Survey Search

The diagram given below includes only the known entity classes within Project 3-I at this writing. The notation below indicates that a survey is identified by its name, and consists of an indefinite number of questions. As this project proceeds, this static model will be expanded to assure that the data definitions support the functionality described in the dynamic models above.

2.4. Class Design Model U.1.3. Edit Survey - TBD

2.5. Class Design Model U.1.4. Delete Survey – TBD

2.6. Class Design Model U.1.5. Preview Survey -- TBD


of 15

3.0. Quality Assurance

The functional modules of Project 3-I will be acceptable to the project sponsors when:

1. Surveys can be created, updated, deleted, and tested.

2. Surveys can be executed by poll takers over the Internet. These polls will be sufficiently user friendly as to keep the survey abandonment rate under 10%. Users wishing to save their surveys and restart them later may do so with a failure rate of less than 1%.

3. Survey data will be available for analysis at the conclusion of the survey and will be 100% in agreement with the selections that were made by the user.

Various automated test tools will be utilized to assure that these testing goals

are met. "User friendliness" will be measured by the use of focus groups drawn randomly from a sample set of Internet users provided by DataSource Inc.

3.1. Specific test cases

3.1.1. Use Case U.1.2 Survey Search

Search parameters Expected result

Survey name (keyword) for completed survey that is on file, date left blank

At least one survey found: Keyword matches parameter entered.

Survey name (keyword) blank, date range inclusive of at least one survey

At least one survey found: Dates within parameter range entered.

Survey name (keyword) any value, date range has ending date earlier than beginning date.

SURVEYPARAMS with the message "Invalid date range." Parameters are solicited again.

Survey name (keyword) any value, at least one date in invalid format.

SURVEYPARAMS with the message "Invalid date range." Parameters are solicited again.

Survey name (keyword) blank, date range inclusive of at least 20 surveys.

Results retrieved are within date range and displayed in pages of SURVSRCH screens in blocks of 15 surveys. Page numbers are hyperlinked at the bottom of the screen and labeled by "Go to Page:" The user can navigate to and from the hyperlinked pages.

Survey name (keyword) blank, date range inclusive of at least 20 surveys.

Results can be sorted by survey name, short description, date created, and date last modified by clicking on corresponding column headers above each field. Each page is sorted in this manner and the results are displayed on pages of 15 each.

Survey name (keyword) for completed survey that is on file, date left blank

At least one survey found: Clicking on survey name hyperlink invokes "Preview Survey" (U.1.5).


of 15

Appendix A: Screen Mock Ups


of 15

Use Case U1.2 SURVEYPARAMS Screen Mock Up

Use Case U1.2 SURVSRCH Screen Mock Up

project 3-i architectural design document · add001 project 3-i architectural design page 6 of 15...

Documents