St. Johns River Water Management District
Station Header Module - Design Stage v1.00
e-Permitting Phase III
Design Stage
Last Revision – May 12, 2003
Release Date -
DRAFT
Page 1Printed 10/06/2018
St. Johns River Water Management District
Station Header Module - Design Stage v1.00
Table of Contents
1.Introduction
1.1.Logical Design
1.2.Physical Design
1.3.When these two design tasks are finished:
2.Executive Summary
3.Detailed Project Organization Chart
3.1.Sponsors.
3.2.Project Manager.
3.3.Business Project Manager.
3.4.Technical Advisor.
3.5.Testers.
3.6.Business Experts.
3.7.Technical Staff.
4.System Flows
4.1.Online Application for Permit
4.2.EN-50
4.3.EN-51 Meter Calibration
4.4.EN-57 Construction Commencement
4.5.EN-45 As-Built Certification
4.6.Well Completion Report
4.7.Batch (AMP)
5.Security Analysis
5.1.Concept
5.2.Authentication
5.3.General Authorization:
5.4.Implementation
5.4.1.Features of the Security filter
5.5.Error Handling
6.User Acceptance Criteria
Printed February 14, 2003Page 1
St. Johns River Water Management District
Station Header Module - Design Stage v1.00
1.Introduction
This document is being used to record the actions taken in the Design Stage of the on-line ePermitting application.
1.1.Logical Design
The design is the first step for the future system. In this subtask, the technical staff thinks in terms of converting the business rules and requirements into a system view, and not in the hardware limitations.
These are the basic steps for the logical design:
- Create System Process Model
- Create Draft Transaction List
- Refine Business Entity Relationship Diagram, if needed
- Refine Logical Data Model, if necessary
- Establish task scenarios (On-line, Batch)
- Develop System Logic Navigation Flows
- Define Application Security Levels
- Define User Interface
- Define User Acceptance Criteria
- Create a Prototype
- Present the prototype to the user
- User Sign Off of Prototype
- CIO Sign Off of Logical Design and Prototype
- Executive Sponsor Sign Off of Logical Design and Prototype
1.2.Physical Design
The physical design portion addresses topics specific to the number of files, file contents, the size of files, and hardware capabilities.
These are the basic physical design steps.
- Identify the Growth Rate for Each Entity (number of transactions expected)
- Identify the number of historical rows required
- Identify Possible Database Performance Problems
- Refine the Logical Data Model
- Create Physical Data Model
- Refine Physical Data Element Definitions
- Define Access Method for Each Table
- Define Secondary Indexes from Logical Transaction List
- Verify Machine Capacity
- Verify Network Capacity
- Identify Possible Hardware Performance Problems
- Prepare the Physical Environment
- Update Physical Design
- Create Development Database
- Refine Prototype
- CIO Sign Off
- Executive Sponsor Sign Off
1.3.When these two design tasks are finished:
- Review code standards
- Complete Design Document
- Obtain the Sign Off of the CIO for Design Stage
- Obtain Sign Off of Executive Sponsor
- Initiate Development and Implementation Stage
Printed February 14, 2003Page 1
St. Johns River Water Management District
Station Header Module - Design Stage v1.00
2.Executive Summary
The design stage of application begins with the creation of the logical design of the database based on the business rules and requirements uncovered in the Analysis Stage of the application development. This logical design is then moved to a physical design which includes table layouts creation, and operating system software, hardware, and network configuration information.
The next stage in the SDLC will be the Development Stage. This stage includes the process of writing the program code to perform the functions defined in the analysis stage of the SDLC process, testing, and planning for implementing the application.
Printed February 14, 2003Page 1
St Johns River Water Management District
Station Header Module - Design Stage v1.00
3.Detailed Project Organization Chart
3.1.Sponsors.
In this case, a team of top managers made up of Deputy Assistant Executive Director, Assistant Department Director from Resource Management. The Executive Sponsors decide the acceptance or denial of the project according to the business objectives.
3.2.Project Manager.
Reports project status and activities to the executive sponsor and committee. Overall coordinator of the project.
3.3.Business Project Manager.
Coordinates business experts /testers with project manager. Assists with business process questions and recommendations. Responsible for the system alignment for the business objectives, and the review of the deliverables’ quality.
3.4.Technical Advisor.
Assures that project meets District technical requirements and standards. Works with technical staff to assist with technical communications.
3.5.Testers.
Users. Responsible for the complete testing and quality assurance of the application.
3.6.Business Experts.
Key users/knowledge workers. Provide understanding of the business requirements, operation, and processes.
3.7.Technical Staff.
Representatives of the District’s technical interests, project developers.
Printed February 14, 2003Page 1
St Johns River Water Management District
Station Header Module - Design Stage v1.00
4.System Flows
4.1.Online Application for Permit
Notes:
** Do I Need a Permit Information Page
This page will assist the user in determining whether to continue with
the application by displaying the conditions under which a permit is
required. These conditions will depend upon the type of permit
application selected.
1. User must have set up 'myaccount' to submit data
2. When user presses SUBMIT
a confirmation number is created
the data is saved to the e-vault (see #3)
the data is saved to the PDS holding tables with date of user save
an email is sent to user with confirmation number and submission message
an email is sent to PDS with confirmation #, application type, etc
3. When SUBMIT is pressed, data should be placed into a form for saving into
e-vault (data stream with save date, data and field wrappers, etc)
4.2.EN-50
Notes:
1. User must have set up 'myaccount' to submit data
2. SAVE allows users (public) to edit Temp Table records until ready to SUBMIT
3. When user presses SUBMIT
a confirmation number is created
the data is saved to the e-vault, with confirmation #
the data is saved to the GRS water use tables
the mail table has a record inserted indicating form was sent
the GRS compliance requirements table is updated with submission date
an email is sent to user with submission message and confirmation #
an email is sent to Regulatory Compliance
4. When SUBMIT is pressed, data should be placed into a form for saving into
e-vault
5. SUBMIT email to Compliance will have confirmation #, application number,
project name, etc
4.3.EN-51 Meter Calibration
Notes:
1. User must have set up 'myaccount' to submit data
2. When user presses SUBMIT
a confirmation number is created
the data is saved to the e-vault, with confirmation #
the mail table has a record inserted indicating form was sent
the GRS compliance requirements table is updated with submission date
an email is sent to user with submission message and confirmation #
an email is sent to Regulatory Compliance
3. When SUBMIT is pressed, data should be placed into a form for saving into
e-vault
4. SUBMIT email to Compliance will have confirmation #, application number,
project name, etc
4.4.EN-57 Construction Commencement
Notes:
1. User must have set up 'myaccount' to submit data
2. When user presses SUBMIT
a confirmation number is created
the data is saved to the e-vault, with confirmation #
the mail table has a record inserted indicating form was sent
the GRS compliance requirements table is updated with submission date
an email is sent to user with submission message and confirmation #
an email is sent to Regulatory Compliance
3. When SUBMIT is pressed, data should be placed into a form for saving into
e-vault
4. SUBMIT email to Compliance will have confirmation #, application number,
project name, etc
4.5.EN-45 As-Built Certification
Notes:
These may be submitted online ONLY if there is no substantial deviation from the
approved plans and specifications
1. User must have set up 'myaccount' to submit data
2. When user presses SUBMIT
a confirmation number is created
the data is saved to the e-vault, with confirmation #
the mail table has a record inserted indicating form was sent
the GRS compliance requirements table is updated with submission date
an email is sent to user with submission message and confirmation #
an email is sent to Regulatory Compliance
3. When SUBMIT is pressed, data should be placed into a form for saving into
e-vault
4. SUBMIT email to Compliance will have confirmation #, application number,
project name, etc
4.6.Well Completion Report
Notes:
1. User must have set up 'myaccount' to submit data
2. SAVE allows users (public) to edit Temp Table records until ready to SUBMIT
3. When user presses SUBMIT
a confirmation number is created
the data is saved to the e-vault, with confirmation #
the mail table has a record inserted indicating form was sent
the well construction tables have the well construction data records inserted
the GRS compliance requirements table is updated with submission date
an email is sent to user with submission message and confirmation #
an email is sent to Regulatory Compliance
4. When SUBMIT is pressed, data should be placed into a form for saving into
e-vault
5. SUBMIT email to Compliance will have confirmation #, application number,
project name, etc
4.7.Batch (AMP)
Notes:
1. User must have set up 'myaccount' to submit data
2. When user presses SUBMIT
the selected data file is copied to the designated directory
the AMP ejb handles the validation of the file
the AMP ejb returns a boolean for the validation results to the e-Permitting ejb.
3. Upon receipt of the validation code, e-Permitting will display the appropriate message (passed or failed - check your mail).
4. Upon receipt of the validation code, e-Permitting will send
a confirmation number is created
the data is saved to the e-vault, with confirmation #
the mail table has a record inserted indicating form was sent
the GRS compliance requirements table is updated with submission date
an email is sent to user with submission message and confirmation #
an email is sent to Regulatory Compliance
4. The email to Compliance will have confirmation #, application number,
project name, etc
Printed February 14, 2003Page 1
St Johns River Water Management District
Station Header Module - Design Stage v1.00
5.Security Analysis
5.1.Concept
The main component that implements the security is “Filter”. A filter dynamically intercepts requests and responses to transform or use the information contained in the requests or responses. Filters are part of the Servlet Specification.
IncomingOutgoing
RequestResponse
One can see from the diagram that the filters are positioned in the processing pipeline, between the application server and the client. A filter provides application level access into the request-handling pipeline of the container. Before the advent of the filters, there was no way for the web applications to participate in the processing being performed along the request-handling path. Due to the strategic positioning of the filters in the request-processing pipeline, they can easily handle the pre- and post-processing of requests for potentially a heterogeneous set of resources (a mix of static HTML pages, JSPs and Servlets.
A filter has access to requests before resource processing.
5.2.Authentication
A user with the intent of entering SJRWMD systems has to be a valid user. This is ascertained by allowing him to enter his login credentials. The login credentials are verified. If verified he is authenticated and thus can be termed as a valid user to enter a system or a group of systems, if the verification process fails, he will not be allowed to enter any SJRWMD system.
The set of information required for the validation of the process falls into “User Information” table that contains various details for a user such as
a)Name (Last, First and Middle Name)
b)Email
c)Password
d)Secret Answer and Question
e)Telephone
f)Address
g)Fax etc
5.3.General Authorization:
An authenticated user does not automatically have access to the entire system or systems. The authorization process will check the business processes that this user can access A business function to which he has access depends on the role that the user falls into. The association of user-role-business function determines whether he is authorized to access a business function. As an example: If a person falling into a role A, may have access to certain business functions but may not have access to other business functions that a person falling into the role B.
5.4.Implementation
The implementation of the security includes an implementation “SecurityFilter.java”, which follows the Filter technology described above. It handles authentication as well as authorization. It would talk to “Security Database”, which needs to be designed and implemented. It also provides for defining certain resources that need not be authenticated or authorized. The “Security Database” would include information regarding users, roles, user-role- resource association.
The Security Filter is defined and then mapped to a URL or Servlet, in much the same way a Servlet is defined and then mapped to a URL pattern.
5.4.1.Features of the Security filter
1)Centralized management of all user access control.
2)Separation of business policies and security policies.
3)Performs authentication and authorization.
4)Eliminates the cost and complexity of building and maintaining access control logic into application.
5)Establish and modify access control policies quickly and easily.
5.5.Error Handling
When a user fails to authenticate, the E-Permitting security allows the user to re-try for a preset number of times. After the authentication attempts fail, an error page is displayed to the user. An error page is also displayed to the user in the event that he is trying to access a resource for which he is not authorized.
Printed February 14, 2003Page 1
St Johns River Water Management District
Station Header Module - Design Stage v1.00
6.User Acceptance Criteria
The Business Experts require a Station Header module that provides GUI richness which follows the Windows interface standards, as set forth in the SJRWMD Documents Standards, and follows the user acceptance criteria already established in the Water Use Permitting module. The acceptance criteria also involves consideration of the following items as the principal needs that must be met by the system.
- Allow users to view, on-line, maps of CUP projects.
- Allow users to print maps of projects from the GRS.
- Provide map display and print options such as
roads
adjacent projects
buffer of five miles
wetlands
background type (SPOT, DOQ, QUAD)
- Allow users to view, on-line, photgraphs of stations.
- Allow secured users to associate digital photographs or sketches with a station
- Improve Quality Assurance to reduce or eliminate duplicate station information.
- On-line access to all station header information
- Access to digitized stations
- Allow users to search for stations meeting spatial criteria without requirement of graphic interface
Printed February 14, 2003Page 1
St. Johns River Water Management District
Development and Implementation v1.00 Not Released
Printed February 14, 2003Page 12-1