Docstoc

State of Alaska Department of Natural Resources

Document Sample
State of Alaska Department of Natural Resources Powered By Docstoc
					State of Alaska Department of Natural Resources




  Resource Authorization System
   Requirements Specification


                      System Design

                             Version 2.1




            1205 East International Airport Road, Suite 100
                       Anchorage, Alaska 99518

                     319 Seward Street, Suite 11
                       Juneau, Alaska 99801

                        Contact Greg Fischer
                          Phone: 770-4115
                            Fax: 561-0159
                     e-mail: gfischer@resdat.com

                         July 23, 2011
Revision #                       Change                    Release Date
   1.0       Initial release                                6/29/2004

   1.1       Addressed comments. See comment log            9/14/2004

   2.1       Addressed comments round 2. See comment log    12/1/2004
Resource Authorization System (RAS)
System Design


1.          INTRODUCTION................................................................................................... 6
     1.1.        PURPOSE ............................................................................................................. 6
     1.2.        SCOPE.................................................................................................................. 6
2.          SYSTEM OVERVIEW .......................................................................................... 7
3.          RAS ARCHITECTURE ....................................................................................... 12
     3.1.    PHYSICAL INFRASTRUCTURE ............................................................................. 13
       3.1.1. Database server ............................................................................................ 13
       3.1.2. Web server .................................................................................................... 14
       3.1.3. Document storage ......................................................................................... 14
     3.2.    EXTERNAL SYSTEMS.......................................................................................... 14
       3.2.1. Integration strategy....................................................................................... 14
4.          DETAILED ARCHITECTURE DESIGN .......................................................... 16
     4.1.    CONVENTIONS ................................................................................................... 16
     4.2.    INFRASTRUCTURE COMPONENTS ....................................................................... 16
       4.2.1. Database ....................................................................................................... 16
       4.2.2. Data-access layer.......................................................................................... 17
       4.2.3. Business logic layer ...................................................................................... 18
       4.2.4. Presentation layer ......................................................................................... 18
       4.2.5. User interface................................................................................................ 19
       4.2.6. Security model ............................................................................................... 19
5.          FUNCTIONAL MODULES DESIGN ................................................................ 22
     5.1.    OVERVIEW OF MODULES ................................................................................... 22
     5.2.    CASE MANAGEMENT MODULE ........................................................................... 24
       5.2.2. Project Sub-Module ...................................................................................... 30
       5.2.3. Milestone Sub-Module .................................................................................. 34
       5.2.4. Action Sub-module ........................................................................................ 38
       5.2.5. Clock Sub-module ......................................................................................... 42
     5.3.    CONTACTS MODULE .......................................................................................... 43
       5.3.2. Notifications sub-module .............................................................................. 47
       5.3.3. Distribution lists sub-module ........................................................................ 49
     5.4.    LOCATION MODULE ........................................................................................... 50
     5.5.    DOCUMENTS MODULE ....................................................................................... 52
       5.5.2. Document Repository .................................................................................... 56
       5.5.3. Document Templates ..................................................................................... 56
     5.6.    RULES MODULE ................................................................................................. 63
     5.7.    GRANTS MODULE .............................................................................................. 67
     5.8.    SECURITY MODULE............................................................................................ 71
     5.9.    APPLICATION MODULE ...................................................................................... 74
     5.10. ADMINISTRATION MODULE ............................................................................... 77
     5.11. REPORTING ENGINE .......................................................................................... 80
       5.11.1. Presentation ............................................................................................... 80

Version 2.1                                                                                9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                  Resource Data, Inc
                                                                     3
Resource Authorization System (RAS)
System Design


6.          CASE TYPE SAMPLE: LUP .............................................................................. 81
     6.1.    TEMPLATE ELEMENTS ....................................................................................... 82
       6.1.1. Phases ........................................................................................................... 82
       6.1.2. Milestones ..................................................................................................... 82
       6.1.3. Actions........................................................................................................... 83
       6.1.4. Rules .............................................................................................................. 84
       6.1.5. Activity Types ................................................................................................ 86
7.          TYING IT ALL TOGETHER – THE CASE TIMELINE IN DEPTH ........... 88
     7.1.    INTRODUCTION .................................................................................................. 88
     7.2.    MILESTONES ..................................................................................................... 88
       7.2.1. Business Definition ....................................................................................... 88
       7.2.2. System Definition .......................................................................................... 88
       7.2.3. Milestone Classes.......................................................................................... 89
       7.2.4. Achieving Milestones .................................................................................... 90
       7.2.5. Notifications .................................................................................................. 90
       7.2.6. Milestone Relationships ................................................................................ 90
       7.2.7. Repeating Milestones .................................................................................... 92
       7.2.8. Consistency Review Example ........................................................................ 92
       7.2.9. Land Use Permit Example ............................................................................ 93
     7.3.    ACTIONS............................................................................................................ 94
       7.3.1. Business Definition ....................................................................................... 94
       7.3.2. System Definition .......................................................................................... 94
       7.3.3. Action Classes ............................................................................................... 94
       7.3.4. Action Log ..................................................................................................... 95
       7.3.5. Action Library ............................................................................................... 96
       7.3.6. Consistency Review Example ........................................................................ 96
       7.3.7. Land Use Permit Process Example............................................................... 97
     7.4.    PHASES.............................................................................................................. 97
       7.4.1. Business Definition ....................................................................................... 97
       7.4.2. System Definition .......................................................................................... 98
       7.4.3. Examples ....................................................................................................... 98
     7.5.    CLOCKS ............................................................................................................. 99
       7.5.1. Business Definition ....................................................................................... 99
       7.5.2. System Design ............................................................................................... 99
       7.5.3. Multiple Clocks ........................................................................................... 100
       7.5.4. Clock Matching (Multiple Stops or Starts in Sequence) ............................. 100
       7.5.5. Consistency Review Example ...................................................................... 101
       7.5.6. Land Use Permitting Example .................................................................... 102
     7.6.    OVERVIEW DIAGRAM OF ACTIONS, MILESTONES, PHASES AND CLOCKS ........ 103
       7.6.1. Actions......................................................................................................... 103
       7.6.2. Milestones ................................................................................................... 104
8.          EXTERNAL INTERFACES ............................................................................. 106
     8.1.        GIS API .......................................................................................................... 106
Version 2.1                                                                              9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                Resource Data, Inc
                                                                   4
Resource Authorization System (RAS)
System Design


     8.2.        LAS: REVENUE AND BILLING (R&B) METHODS ............................................. 110
     8.3.        RAS METHODS FOR R&B ............................................................................... 113
     8.4.        LAS: CUSTOMER INFORMATION SYSTEM (CIS) METHODS ............................. 114
     8.5.        LAS: CASE MANAGEMENT (CM) .................................................................... 115
     8.6.        ONLINE CREDIT CARD PROCESSING ................................................................ 116
     8.7.        LDAP EMPLOYEE DIRECTORY ........................................................................ 117
     8.8.        LOGGING ......................................................................................................... 117
9.          STANDARDS ...................................................................................................... 119
     9.1.        CODING STANDARDS AND NAMING CONVENTIONS .......................................... 119
10.         GLOSSARY......................................................................................................... 120




Version 2.1                                                                             9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                               Resource Data, Inc
                                                                   5
Resource Authorization System (RAS)
System Design



1. Introduction
1.1.      Purpose
This document is a complete system design for the Resource Authorization System (RAS).
Its purpose is to provide a detailed description of the features of RAS as well as a technical
blueprint to develop the system.

1.2.      Scope
RAS will improve the way DNR issues and administers its land-use and ACMP
authorizations. In the initial implementation of RAS, the following processes will be
supported:
         ML&W Land Use Permit (LUP)
         ML&W Commercial Recreation Permit (CRP)
         OPMP Consistency Review (CR)
         OPMP Grant administration
         OMPM Coastal Plan Management
RAS will improve productivity within the DNR by providing staff with tools that allow them
to make decisions more consistently and effectively, as well as reduce any duplicated efforts.
Within the system, management reports and monitoring tools will provide enhanced visibility
into the decision process for staff and the public. Decisions tracked in RAS will be
documented consistently, limiting the DNR‘s exposure.
RAS is designed with the flexibility to accommodate the expected future expansion into
other authorization types as well as integrate with existing business systems.
RAS will provide a higher degree of visibility and predictability to DNR processes for the
public. Members of the public will have access to new and improved tools to interact with
the DNR, to locate more accurate information, provide an accurate public record, and to
receive more predictable results when working with the DNR.
RAS is a modular system, providing extensive functionality throughout. Its features include:
         Template-based case management system that can be used for many types of
          processes
         Complete contact management system
         Document repository
         GIS-based land system
RAS is designed on industry-standard patterns and technologies specified by the DNR. The
system is to be maintained and administered by DNR and will include a complete system
administration component.



Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                              6
Resource Authorization System (RAS)
System Design



2. System Overview
RAS will meet the needs of two divisions within the DNR – the Division of Mining, Land,
and Water (ML&W) and the Office of Project Management and Permitting (OPMP). Though
the two groups do have some unique needs, they also have many requirements in common.
The ML&W division is comprised of three regions – Southcentral, Northern, and Southeast.
Each division handles requests for a geographic area of the state. Each region provides public
support, through a Public Information Center (PIC), and has a full staff of adjudicators,
managers, and points of contact. RAS will support ML&W staff in the Land Use Permit and
Commercial Recreation Permit processes.
The OPMP, which is also responsible for the Alaska Coastal Management Program (ACMP),
is primarily located in Juneau. RAS is designed to assist OPMP in conducting Consistency
Reviews, managing Coastal Plan reviews, and grant administration. Members of OPMP are
Project Review Coordinators (PRC), Project Review Administrators (PRA), and grant
administrators.
RDI has conducted extensive user interviews, business analysis, and technical analysis to
discover and document the requirements of RAS. Detailed system requirements can be found
in the Use Case document (Deliverable 1.4) located at www.resdat.com/dnr/deliverables.
That analysis highlighted the following requirements:
         The system must allow flexibility – it can‘t constrain adjudicators and limit their
          ability to do their primary task of making decisions
         Users want to gain insight into how the case fits into the larger context
         System should provide predictability to the process so customers understand how to
          do business with the DNR
         System should provide measurability – true measurability – so users can understand
          how long it took to process a case, and how long the DNR was waiting on others
          before continuing processing
         System needs to help adjudicators manage their workload
         It must be easy to get useful information out of the system, otherwise users won‘t put
          information into it
RDI has reviewed and analyzed these requirements to develop this design of RAS. Our
approach was to define several key areas of functionality – such as case management or
contacts – and develop a model around these areas. At each step in the design we test the
design with real business problems, and refine it as necessary. Finally, we critique our design
against the original vision for the system and ask, ―Are we adding value?‖ and ―Are we
solving business problems?‖
The completed design defines a group of functional modules, each providing key
functionality, and lays the groundwork for an enterprise-level, business-oriented system that
adds value to DNR by:

Version 1.1                                                    9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                      Resource Data, Inc
                                                7
Resource Authorization System (RAS)
System Design


         Increasing productivity of DNR staff through minimizing manual data entry, data
          manipulation, correspondence, and report creation
         Standardizing and streamlining the permitting process and improving the experience
          for the public
         Accelerating resource authorizations and review for the public
         Capturing and reporting on key performance metrics
RAS is comprised of the following functional modules:
         Case management module providing flexible and extensible case management
          functionality
         Contacts module giving users the ability to organize, manage, and use contacts in a
          variety of ways
         Location module, including GIS integration
         Documents module providing storage and retrieval of documents
         Rules module supporting enforceable policies, alternative measures, and stipulations
         Grants module supporting OPMP grant-administration effectively
         Security module providing data-security and supporting personalization
         Application module supporting collecting and storing application information online
         Administration module providing a user interface for system configuration
Case management
The case module can be considered the heart of RAS, the core of the functionality required
for staff to do their jobs. A RAS case is an abstract concept – it does not contain details of the
information specific to the case such as quantity of material or length of stay in an area.
Rather, it contains the information necessary to process cases of a certain type; adjudicators
continue to make the decisions about the details of the case.
A case can be described as having a status and being of a certain type. A case contains:
         A list of contacts involved with the case
         A description of the activity
         A location where the activity is going to take place
As a case is processed, other information is maintained, including:
         Documents relevant to the case
         Events important to the case history
         Important dates to DNR or the applicant
         Stipulations or rules applicable to the case

Version 1.1                                                      9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                        Resource Data, Inc
                                                 8
Resource Authorization System (RAS)
System Design


         Activities and other cases related to the case
The case module is based on the paradigm of a template. A template is something that serves
as a master or a pattern; similar items are made from the template. The item created from the
template can be manipulated or tweaked after it is created, but it is still based on the original.
The template metaphor serves the RAS design well: it provides consistency to case
management while maintaining flexibility. Cases can also be configured to any process that
requires the functionality described above. A complete administrative interface is included in
RAS. In addition to the standard administrative tasks – adding lookup list values,
administering user accounts – the interface will include a wizard to maintain and add new
case type templates. Modifications can be made to the case template without new coding.
A case type template contains parameters that determine how cases of that type will exist in
RAS. The template includes default milestones of the case, the phases the case will progress
through, the list of valid action types for each phase, a default set of contacts, and a default
set of rules that apply to cases of that type.
Once the case is in RAS, it is processed by the user taking different actions. RAS will record
all of these actions in an action log. An action can impact the case in a variety of ways –
sending notifications, changing case status, moving the case to another phase, etc. The case
timeline is expressed through a list of milestones representing major events in the case
lifecycle.
The OPMP requirements also dictated the need for a case clock. For example, consistency
reviews have a ―clock,‖ a set amount of time they must be completed in. In RAS, the clock is
the mechanism used to understand how to interpret the time between major events both that
have occurred and are scheduled.
Through user interviews we discovered there was a need to group cases, or provide a higher
level structure to provide a context to a set of cases. Within DNR there is a concept of a
project, and RAS encompasses that concept. The project describes what the applicant is
doing – the activity, the general location, the people involved – while the cases are the actual
permits and reviews they will need to complete. Projects also can be categorized (mining,
agriculture, oil and gas, etc.) and used to record information not applicable to any one case.
An example of a typical project might be the process of building a dock. The dock is the
project, but there will be two cases associated with the project – a land use permit (case 1)
and a coastal consistency review (case 2).
Contacts
RAS includes a contact management system that features two main entities – the contact and
the organization. Primarily based on the requirements of OPMP, the contacts module is fairly
robust and designed to be leveraged in other parts of RAS.
A contact is simply a person who is involved with DNR in some capacity. This contact may
have several organizations they are related to, each in a different capacity or role. For
instance, a single person may be responsible for obtaining permits for oil drilling relating to
their job; may also be applying for a permit for personal use like building a dock at their
cabin; may be interested in any activity next to their home residence; and, they may be on the
distribution list for any activity in their favorite hunting spot.
Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                                9
Resource Authorization System (RAS)
System Design


Location
Location is a central concept to DNR – everything revolves around the location of a given
activity. RAS will include a GIS interface, allowing users to indicate areas of concern and
activity in a graphical format. DNR staff will be able to use these tools to do location-based
searches.
Rules
Between the two divisions there are several different types of regulations, guidelines, and
rules that are used in cases. For example, the OPMP attaches alternative measures to a
consistency review, and references enforceable policies. In ML&W, most permits carry
stipulations when issued to the permittee, and the permittee must complete reports and
actions throughout the life of the permit. In RAS, we have encompassed these business
requirements into a separate functional module called the rules module.
The rules module allows stipulations and alternative measures to be attached to a case. Once
a rule is used in a case, DNR staff can configure reporting requirements, as well, such as the
requirement to submit annual reports, report visitor counts, or pay annual fees.
Rules also cover the standing rules tied to a location or a certain case type. The rules module
includes a rule bank. The rule bank allows rules to be changed, have changes tracked, and
opens the process up to comments from the public. This feature is especially important as
enforceable policies are reviewed and modified by the coastal districts.
Grants
RAS includes a grants module to track grant funds, facilitate reporting by recipients, and
allows the OPMP to easily create necessary reports. This module allows grants to be tied to a
project in RAS, and leverages the other modules to store documents and manage contacts.
Documents
We have designed this system with the aspirations that it will be the single source of
information with DNR for the case types managed by RAS. However, RAS is not intending
to replace the paper case file at this time. The documents module is designed to allow as
much information as possible to be stored electronically, with access through a common
interface.
This module contains a document repository which provides the basic functionality to store
and retrieve documents of any type, as well as maintain different versions of the same
document. The documents module is designed so that if, at a later point in time, DNR decides
to migrate to a full-featured document management system, RAS will be able to easily take
advantage of it.
Document templates are used within an organization to gain consistency among different
users, and DNR staff require the automatic generation of documents in order to gain
efficiency. The documents module includes the capability to add templates that can be
populated with data directly from RAS. For example, a land use permit template will exist in
RAS. When the user issues the permit, RAS will automatically merge the permit template


Version 1.1                                                 9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                   Resource Data, Inc
                                             10
Resource Authorization System (RAS)
System Design


with data from RAS and provide a pre-filled permit to the user. This feature will increase
productivity and promote consistency within DNR.
User Interface and Security
RAS supports a variety of users – DNR staff who will use the system everyday and the
general public only interested in obtaining basic information. RAS will include a web based
interface, allowing the system to scale as necessary and providing accessibility to a wide
audience.
The screens have been designed for the system, and several different screen types have been
identified. There are several processes that represent complex logic and user interaction. For
these tasks, the entire process has been wrapped up into a wizard interface.
A role-based security model is included, allowing data and interface elements to be restricted
or modified based on the user role. Different user communities have different vocabularies –
stipulations versus alternative measures, for example – and so the design includes facilities to
change screen prompts based on the user role.
Conclusion
The modules described here, and the detailed and complete list following, represent the
complete design for RAS. This system is designed to be usable and achieve the goals
outlined in the beginning of this document.




Version 1.1                                                 9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                   Resource Data, Inc
                                             11
Resource Authorization System (RAS)
System Design



3. RAS Architecture
The general architecture of a RAS conforms to an industry standard n-tier architecture
approach. In this type of architecture, the system can be divided into horizontal slices
representing logical layers or tiers – a data access layer, a business logic layer, and a
presentation layer.

                                                                                                                                   GIS
    Client




                             Internet Explorer                    Netscape                   HTML 4.0 browser


                                                                                                                               Credit card


                                                              Documents                                  Administration
    Presentation




                     Case module         Rules module                              Grants module
                                                               module                                      module
                       screens             screens                                    screens
                                                               screens                                     screens

                                                    Application
                             Location module                             Contacts module    Security module
                                                     module
                                 screens                                     screens           screens
                                                     screens




                                             Screen controller object (Struts)




                                                              Documents                                  Administration
    Business logic




                     Case module         Rules module                              Grants module
                                                               module                                      module
                       objects              objects                                   objects
                                                               objects                                     objects
                                                                                                                                    LAS
                                                    Application
                             Location module                             Contacts module    Security module
                                                     module
                                 objects                                     objects           objects
                                                     objects




                                                             ORM objects
    Data access




                                                                  DBCP


                                                                  JDBC




                                                          Database




Enterprise systems with the importance and complexity of RAS require n-tier architecture for
several reasons. Some of the benefits of this approach are:
Version 1.1                                                                                        9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                          Resource Data, Inc
                                                                           12
Resource Authorization System (RAS)
System Design


         The system is scalable – hardware or configuration changes can be made to each layer
          to allow the system to scale to meet user demand
         Lower total cost of ownership – the system will require changes, enhancements, and
          maintenance and it becomes more and more central to the DNR business. In an n-tier
          architecture, not only is finding the piece of software to change easier, but testing and
          releasing the change is quicker.
         The system is reliable – the less time it takes to make changes, do upgrades, or fix
          bugs is the less potential down time
         The system is responsive – changes and enhancements requested by business users
          are easier to accommodate, and users see their requests implemented more quickly
         Developers can choose the right tool for the right job – different developers can work
          on different layers in the technology they are most competent in (i.e. a DBA can
          manage the database, a Java programmer codes the business logic, and a designer
          creates the web pages)
         Promotes reuse – the logic for a certain module is written once in the business layer
          and then different interfaces access the same piece of logic
RAS will be built on J2EE (Java 2 Enterprise Edition) technology. Each layer has discrete
roles and capabilities within the architecture.
The data access layer handles all access to the database, including connections, connection
pooling, and basic database operations (create, read, update, delete, or CRUD operations).
This layer will be implemented using Object/Relational Mapping (ORM), Java Database
Connectivity (JDBC) connection-pooling, and Java Beans (Java) representing system
entities.
The business layer is the brain of the system, containing the implementation of business
rules, formulas, and logic. Centralizing this complex code into a single area reduces the
impact of changes and decreases the amount of time to change, test, and deploy. Much of the
business layer is displayed in this document in the object models for each module.
The presentation layer displays the application to the user, validates user input and controls
the user interface (hiding and showing controls, etc.). This layer will be implemented using
the Struts framework.

3.1.      Physical infrastructure
     3.1.1. Database server
The database server will be Oracle Enterprise 9i and will be hosted on Solaris servers (versions
8 and 9) on Sparc architecture. Standard backup procedures will be implemented on the
development and production servers as specified in the RAS IT Requirements Specification
document (Deliverable 1.5) located at www.resdat.com/dnr/deliverables.



Version 1.1                                                    9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                      Resource Data, Inc
                                                13
Resource Authorization System (RAS)
System Design


     3.1.2. Web server
The web and application server will be the production release of Jakarta Tomcat 5.0.16. The
web server will be hosted on a Sun 1U dual-Xeon machine running Sun JDK 1.4.

     3.1.3. Document storage
Originally the document management component of RAS was going to be another external
interface for RAS to use. However, that option is not available, and this project will include
the implementation of a document repository. Documents will be stored in a document
repository, as described in the Documents module design.

3.2.      External systems
Please reference the external interfaces document in the appendix of this document. To
summarize, RAS will be integrating with the following systems:
     DNR Spatial Database
          All operations requiring GIS-type services will be conducted through the DNR
          Spatial Database. This will include geographic selections, geographic entry of
          location data, and coordinate conversion.
     LAS Case Management system
          LAS is still the central case management system at DNR. Many other systems
          interface with LAS. RAS will only support a small subset of all the available
          authorizations at start up. Given this, LAS must be synchronized with RAS at all
          times. The goal is real time synchronization; this will be a one way synchronization
          from RAS to LAS at the time data is committed in RAS.
     LAS Revenue and Billing (R&B)
          RAS will store no financial data, nor will it support financial transactions. All
          operations involving financial data will be channeled through an interface to R&B.
     LAS Customer Information System (CIS)
          The eventual goal is for the contacts module developed in RAS to become the central
          CIS system for DNR. At the current time, customer information is entered through a
          variety of processes, most involving LAS. Until this is changed, customer
          information will by updated via a one way synchronization from RAS to LAS.
     State of Alaska LDAP directory
          State employees will be authorized through the State‘s LDAP directory.
          Unfortunately this will result in multiple security schemes being implemented with
          RAS, but the convenience for state employees will make it worth it.

     3.2.1. Integration strategy
RAS has been designed in several functional modules. Within RAS, some modules are
dependent on other modules (i.e. Cases are dependent on Contacts). In order to insulate

Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                              14
Resource Authorization System (RAS)
System Design


changes to a module from impacting other modules dependent on it, we will adopt a loosely-
coupled integration strategy. Access to a module will be provided through a published
interface – when a module does change, only the interface must be tested, not all the
dependent modules.
Additionally, some modules have dependencies to external systems (like the State of Alaska
LDAP directory). If a RAS module is dependent on external systems, a separate ―interop‖
object will be programmed to act as a central interface, or ―shim,‖ to interface with the
external system. Again, this strategy has been adopted to insulate RAS from changes to the
external system. RAS components will always communicate with the interop object. If
changes are made to the external system, only the interop object will need to be modified, not
any RAS internal objects.




Version 1.1                                                9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                  Resource Data, Inc
                                            15
Resource Authorization System (RAS)
System Design



4. Detailed Architecture Design
4.1.      Conventions
Within this design document we have used some conventions to help communicate the
design to a wide audience. The object models are designed to document the design to
developers, but also communicate the intended business logic to business users. For purposes
of simplicity and clarity we use the following conventions in UML for object models:
         The data layer object model is not shown. It is implied that the data layer will be
          implemented as a manifestation of the physical data model using ORM standards
         Many of the object models represent Beans with private members, but no accessor
          methods. If not otherwise noted, there are public methods getXxx and setXxx for all
          private members xxx on beans representing system entities

         Collection    members of beans are represented as being of type Collection, though
          their declared type is likely to be some subclass of Collection in the delivered
          system.
         Aggregate members of beans requiring accessor functionality beyond that of simple
          getters and setters are represented as inner classes rather than as Collections.

4.2.      Infrastructure components
     4.2.1. Database
RAS will be built in the Oracle environment. The basic database architecture is shown in the
diagram below. All tables will be access through views. The views will control access to the
data through joins into the security schema. The base tables will all be locked to prevent
direct access.




Version 1.1                                                    9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                      Resource Data, Inc
                                               16
Resource Authorization System (RAS)
System Design




                                                Data access

                            User
                            Role         Database Security
                         Permissions



                                  Insert View             Select View(s)




                                                 Base Table



                       Figure 1: Database access architecture overview
The RAS physical data model is a separate deliverable, but part of this system design.
Additional database objects, including stored procedures, views, and triggers will be detailed
within each module, or created as needed during development, and then appropriately
documented.

     4.2.2. Data-access layer
The RAS data-access layer will be a complete implementation of an enterprise data access
layer. This typically includes a standard method for persisting data, performing CRUD
actions, and connection pooling.
The connection-pooling service handles connecting over JDBC to the Oracle schema, and
making connections available as needed to system processes. The time to create a new
connection can often take seconds, while the actual database transaction may only take a few
milliseconds. Rather than opening a new connection for each database call, it is preferable to
have all users share a "pool" of open connections. The number of users actually performing a
request at any given time will be a small percentage of the total number of active users, and
the database connection is required only during request processing. The application logs into
Oracle itself and handles any Oracle user account issues internally.
The RAS data access layer will include the following:
         A JDBC connection-pooling service such as Jakarta Commons DBCP
         Hibernate ORM (Object/Relational Mapping) framework for persistent data storage.
          This framework allows data in Oracle, a RDBMS, to be persisted following common
          Java idioms including association, inheritance, polymorphism, composition and the
          Java collections framework


Version 1.1                                                     9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                       Resource Data, Inc
                                                  17
Resource Authorization System (RAS)
System Design


         Java Beans (Java classes following the Bean pattern—private members with public
          accessor methods) representing persistent system entities
         Factory classes providing methods for creation, lookup, instantiation, and updates of
          Beans.
The benefits of this design for data access are:
         ORM is state-of-the-industry technology. It is well known and well documented,
          such that developers, maintainers, and administrators will find that the system‘s
          implementation follows familiar and established patterns, and that documentation is
          widely available
         This architecture will cut development time and costs significantly by comparison to
          developing a custom persistence framework and JDBC connection-pooling service.
         These technologies leverage the expertise and manpower of hundreds of developers
          working to continually improve, extend, and enhance these frameworks
We have chosen Hibernate as the ORM framework as it is an industry leading product will
complete support by the open-source community. Likewise, DBCP is the most mature of the
JDBC connection-pooling services supported by Hibernate. Both of these products are open-
source, community-developed software, licensed under LGPL, and has earned critical
industry acclaim.

     4.2.3. Business logic layer
The business logic layer is a logical layer that exists to provide a separation between business
logic and presentation logic. The business logic obtains data directly and exclusively to the
O/R-mapped Beans and Factories in the data-access layer. Similarly, the Struts controller in
presentation layer relies on this layer.
As mentioned, the object models in this document are designed to show the business logic,
but are a bit of a hybrid of data objects and business logic. The implication is that the final
implementation may look differently than the design presented - logic depicted in a base
object may actually be implemented as static methods in a utility class.

     4.2.4. Presentation layer
The presentation layer will be implemented using the Struts framework and a standards-
based web presentation technology. At the core, the Struts framework provides a flexible
control layer. The Struts framework interacts with standard data access technologies, like
JDBC and Hibernate.
For the presentation technology, we will plan on using standard Java Server Pages (JSP).
However, it is worth noting that JavaServer Faces (JSF) has recently been accepted by the
Java community. This technology simplifies building user interfaces for Java applications.
Developers of various skill levels can quickly build web applications by assembling reusable
UI components in a page; connecting these components to an application data source; and


Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                              18
Resource Authorization System (RAS)
System Design


wiring client-generated events to server-side event handlers. At implementation time we will
investigate using JSF and evaluate the development and maintenance benefits to RAS.

     4.2.5. User interface
The RAS user interface has been designed and documented in deliverable 2.3 Screen
Prototypes. In general, each functional module lists the screens included in the module, as
well as their type. The Screen Prototypes document identified several types of screens we
will use in RAS, including:
         Wizard
         Query
         Detail
         Detail navigation
Each screen will include client-side validation to provide users immediate feedback on data
input; this will consist of validations such as date format, required fields, etc. Additional and
more complex validation can be implemented programmatically at the business logic layer,
where needed.
As a rule, fatal exceptions will be handled at the appropriate layer (database exceptions at the
data layer, etc.). If the exception is unhandled at the initial invocation, the calling layer will
either add logic to handle the exception, or rethrow the exception, until it is presented to the
user interface in a user-friendly manner. A common set of user-friendly error pages will also
be created for any unhandled fatal exceptions and standard web errors (i.e. file not found,
etc.) These will be configurable so developers or administrators trying to debug a problem
can see the full error message, but end-users will see a friendlier page with just contact
information.
Each screen will also contain a unique identifier (page title) that will be used to integrate with
the role-based security model to identify to the user the page they are a viewing. A hidden
key containing the version number will also be automatically maintained on the page to assist
in debugging and supporting end users.
The user interface will also tie into the RAS security model. Based on a user‘s role, screen
items may be rendered differently. For one role, the screen item will not display; for another
role, the label for the screen item will be personalized. Screen items can be made active or
inactive, visible or hidden, or have the prompt changed based on the user role.
Please refer to the Screen Prototypes document (Deliverable 2.3) located at
www.resdat.com/dnr/deliverables for complete information on look-and-feel, screen types,
and navigational paradigm.

     4.2.6. Security model
 Please refer to the Security Requirements document (Deliverable 1.9) located at
www.resdat.com/dnr/deliverables for complete information on users, roles, authentication,
and access levels.

Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                              19
Resource Authorization System (RAS)
System Design


Within RAS, all objects can be assigned a unique identifier. This id is then used to apply
permission to if for a given user. The security model will be role-based with permissions
being granted to objects and users being assigned roles. At run time, when a user logs in, they
will be assigned a role or roles, and the security model will dictate their level of access based
on their roles.
As a default, if an object is not listed in the RAS security tables, all users will have full
access to it. Once the object is listed in the tables only users with roles specified will have
access to the object. This is considered the global security model.
Beyond the global security model, RAS provides the capability for users to have different
roles for case types they are accessing. A user may be an adjudicator for Land Use Permits,
but only have public level access for Consistency Reviews.
Finally, RAS provides a temporal aspect to security – the permissions can change in a case
based on the milestones reached. An administrator will create logical groupings of security
permissions, called a security profile that can be assigned to the case template by a template
administrator. Template security will work much the same as global security – roles will be
given permissions to objects associated with the template.
Obviously, a user may have multiple sets of permissions applied to their identity at any given
time. The system will take the least restrictive approach to reconciling differences – if any of
the profiles grant permission to the user for the object, the system will allow access to the
object.
The logic flow of the security system is demonstrated below:
   1. Login
           a. When the user initiates RAS, the system will determine who the user is.
              Inability to determine a user‘s role will cause them to be ‗public‘.
           b. RAS will load the user‘s roles and associated permissions into a data structure
              in memory. Upon login, the system default security profile for the user‘s roles
              will be loaded.
           c. This security ‗state‘ will be used until one of the following occurs.
   2. Select a case to work with
           a. When the user selects a case to work with, RAS will determine the last
              milestone achieved for the case.
           b. If no milestones have been achieved, the default security profile will be
              loaded for the user‘s roles
           c. If a milestone has been achieved, RAS will check if a security profile is
              associated with that milestone. If so, the security profile will be loaded for the
              user‘s roles.
   3. Work on a case
           a. As the user makes changes to the case, their security may change as
              milestones are achieved.
           b. When a milestone is achieved, RAS will check if there is a security profile
              associated with the milestone.
           c. If a security profile is associated with the milestone, RAS will immediately
              load it for the user‘s roles.
Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                              20
Resource Authorization System (RAS)
System Design


              d. If no security profile is associated with the case, security will not change
RAS will provide an authentication mechanism for users; each user will be authenticated at
the start of their session and the user credentials will be maintained through the life of the
session. State employees will be authenticated against the Alaska LDAP server instead of
RAS.




Version 1.1                                                    9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                      Resource Data, Inc
                                                21
Resource Authorization System (RAS)
System Design



5. Functional Modules Design
5.1.      Overview of Modules
The design of RAS has been broken up into several functional modules. These modules
include:
     Case Management module
          This module is the heart of RAS. It is a generic case management system, supporting
          template-based configuration of case types. This provides the ability to model new
          case types with custom behaviors; it will allow RAS to easily expand to handle new
          authorization types.
          This module is composed of several sub-modules including:
                 Projects sub-module
                 Milestones sub-module
                 Actions sub-module
                 Clocks sub-module
          In this version, this module will integrate with the LAS Case Management system.
     Contacts module
          This module can almost be considered a stand-alone contact management system
          providing rich functionality to organize, manage, and use contacts in a variety of
          ways. Information stored in this module includes information about case contacts and
          applicants.
          Two sub-modules also belong to the Contacts module, include:
                 Notifications sub-module
                 Distribution lists sub-module
          In this version the Contacts module will integrate with the LAS Customer
          Information System (CIS).
     Location module
          At the core of this system is a GIS application, allowing a graphical interface into all
          location-specific information. RAS will use the reference spatial information in
          several other areas, including projects, cases, grants, and others.
     Documents module
          The documents module provides the facility to store, maintain, search, and retrieve
          documents. Documents can have optional keywords applied to them when they are
          stored in the repository, to allow for generic searching, and can also be associated
          with other RAS entities, such as cases or grants.

Version 1.1                                                    9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                      Resource Data, Inc
                                                22
Resource Authorization System (RAS)
System Design


          A couple sub-modules make up the Documents module. They are:
                 Document repository sub-module
                 Document templates sub-module
          The document templates sub-module allows the ability for users to generate standard
          documents dynamically from boilerplate templates.
     Rules module
          The Rules module provides the facility to add, update, and manage rules –
          enforceable policies, attorney general opinions, etc. The case module uses rules
          extensively as case rules (stipulations, alternative measures, etc.) that are based on or
          supported by other rules (enforceable policy, etc.). In other case types, like plan
          management, rules will be created or modified as the case progresses.
     Grants module
          This module allows OPMP users the ability to track grant funding and report on
          allocation and tracking of grant funds. Grants can also be used to fund projects.
     Security module
          The Security module encompasses system security – users, roles, access and
          authentication – as well as understanding how to use organizations (part of the
          Contacts module) and integrate with the State of Alaska LDAP directory.
     Application module
          This module is lightweight, as we expect other initiatives to replace this piece of
          RAS. This module covers permit applications for Land Use Permits and Commercial
          Recreation Permits, as well as the Coastal Project Questionnaire.
     Administration module
          The administration module is the system for maintaining all of the other modules.
          This module includes the facilities to update and maintain lookup list values and
          security tables. This module also includes the administration of the case type
          templates.
The following diagram provides a visual overview of the RAS system with the modules and
sub-modules identified. The external systems with which each module integrates are
identified in each module‘s description.




Version 1.1                                                     9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                       Resource Data, Inc
                                                23
Resource Authorization System (RAS)
System Design


                                       Project          Milestones

                                     Clock                  Actions



                                                 Case


                            Rules                               Location

                                                                                                         LUP
        Repository

        Templates
                     Documents               RAS                       Application                       CPQ

                                                                                                         CRP



                                                                                               Notifications
                          Grants                                      Contacts               Distribution Lists




                        Administration                       Security



                                 Figure 2: Module overview


5.2.      Case management module
The Case Management module is the heart and soul of RAS. A case is the means to track a
process, notify others about the process, have others participate in the process, and report on
the process. The case may or may not have an outcome, like a permit, but it will have certain
milestones it is accountable to, actions that are recorded as the case is processed, clocks to
track the temporal aspects of the process, and projects to organize and categorize multiple
cases.
The case management module has several other components that complete the data necessary
to effectively understand a case. A case has contacts – people that have some vested interest
in the case, maybe as an applicant, another agency, or a concerned adjacent land-owner. A
case also must have a location – the areas the case is primarily concerned with. Documents
play a key role in case management – much of the data relating to a permit is submitted and
stored as documents in a document repository. Document templates will also be used
extensively in the case management process to generate standard documents – notices,
permits, decisions, etc. – and then these documents will be stored in the repository. Finally,
the rules module will provide a resource for users to quickly and uniformly apply parameters
– stipulations, alternative measures, etc. – to the case.


Version 1.1                                                           9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                             Resource Data, Inc
                                                 24
Resource Authorization System (RAS)
System Design



                                   Project        Milestones

                                Clock                 Actions


                                        Case

                Documents               Contacts                  Application

                               Rules                 Location



                       LAS                                 Credit Cards
                               Figure 3: Case Management

     5.2.1.1.   Database
Here are the tables used in the case management module:
                  Table name                                     Topic area

CASE                                              Cases
CASE_ACTION                                       Cases
CASE_ACTION_DOCUMENT_XREF                         Cases
CASE_ACTION_TYPE                                  Cases
CASE_ACTION_TYPE_DOC_XREF                         Cases
CASE_ACTION_TYPE_MILESTONE_XREF Cases
CASE_ACTION_TYPE_PHASE_XREF                       Cases
CASE_ACTIVITY_TYPE                                Cases
CASE_APPLICATION                                  Cases
CASE_COMMENT                                      Cases
CASE_COMMENT_CONTACT_XREF                         Cases
CASE_COMMENT_TYPE                                 Cases
CASE_CONTACT                                      Cases
CASE_CONTACT_PREFERENCE                           Cases
CASE_CONTACT_PREFERENCE_TYPE                      Cases
Version 1.1                                                9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                  Resource Data, Inc
                                             25
Resource Authorization System (RAS)
System Design


CASE_CONTACT_TYPE                               Cases
CASE_DESCRIPTION                                Cases
CASE_DOCUMENT                                   Cases
CASE_DOCUMENT_TYPE                              Cases
CASE_LOCATION_XREF                              Cases
CASE_MILESTONE                                  Cases
CASE_NOTE                                       Cases
CASE_RULE                                       Cases
CASE_STATUS_TYPE                                Cases
CASE_SUB_TYPE                                   Cases
CASE_TYPE                                       Cases
CASE_TYPE_RULE                                  Cases
ACTIVITY_TYPE                                   Cases
LAS_CASE_SUB_TYPE                               Cases
LAS_CASE_TYPE                                   Cases
RELATED_CASE                                    Cases
RELATED_CASE_TYPE                               Cases

     5.2.1.2.   Business logic
This module covers the following use cases:
                Use cases                                     Use cases

1.12 Check application status                  2.21 Comment on application
2.1 Start a new case                           2.22 Address comments
2.6 Record pre-application interview           2.34 Maintain case file location
2.7 Create a new project                       2.35 Appeal decision
2.8 Add a case to a project                    2.41 Update case description
2.9 Route case file                            2.42 Start a new case from an existing
                                               case
2.10 Assign case owner                         2.43 Start a new case from an
                                               application
2.11 Initiate case                             3.9 Search cases
2.15 Record case notes                         10.1 Submit payment
Version 1.1                                              9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                Resource Data, Inc
                                          26
Resource Authorization System (RAS)
System Design



The object model below represents the business logic layer of the application for the case
management module.
                                                0..*                         Case                                                                   RelatedCase
                                                       +   caseId                   :   int                       1          0..*    +   relatedCaseId        :   int
                                                       #   project                  :   Project                                      +   case                 :   Case
                                                       -   label                    :   java.lang.String                             +   relatedCaseType      :   java.lang.String
                           1                           +   caseType                 :   java.lang.String                             +   notes                :   java.lang.String
                                                       +   caseSubType              :   java.lang.String                             + updateRelatedCaseType () : void
                                                       +   application              :   Application
                 Cases                                 +   fileLocation             :   java.lang.String
                                                       +   activities               :   Array
                                                       +   createDate               :   java.util.Date                                            CaseDescription
        + sort ()         : void
        + find ()         : Case                       +   templateId               :   int                                          +   caseDescriptionId    :   int
                                                                                                                  1         0..*
                                                       +   description              :   CaseDescription
        + add (Case case) : void                                                                                                     +   case                 :   Case
                                                       +   owner                    :   Contact                                      +   description          :   java.lang.String
                                                       +   caseMilestones           :   MilestoneGraph                               +   createDate           :   java.util.Date
                                                1      +   relatedCases             :   Collection
                                                       +   caseNotes                :   Collection
                                                       +   activityTypes            :   Collection
                                                       +   caseDescriptionHistory   :   Collection                    1
                   0..*
                                                       +   caseLocations            :   Collection
                                                       +   distributionLists        :   Collection
              CaseNote                                                                                                                                                0..*
                                                       +   caseDocuments            :   Collection
    +    caseId       :   int                          +   addCaseAction ()                      :   CaseAction
    +    caseNoteId   :   int                          +   addDocument ()                        :   void                                           CaseActivityType
    +    author       :   Contact                      +   addCaseNote ()                        :   void                                   + caseActivityId : int
    +    contact      :   Contact                      +   addRelatedCase ()                     :   void                                   + activityType   : ActivityType
                                                       +   updateCaseDescription ()              :   void                                   + Notes          : int
                                                       +   addToProject (Project project)        :   void
                                                       +   routeCase ()                          :   void
                                                       +   initiateCase ()                       :   void
                                                                                                                      1
                                                            CaseContacts
                                                            CaseComments




                               CaseContacts
                                                                                                                                                    ActivityType
                                                                              CaseComments
                                                                                                                                     +   activityTypeId           :   int
                                                                       + caseComments : Collection
                  +   sort ()             :   void                                                                                   +   parentActivityType       :   ActivityType
                  +   find ()             :   CaseContact                                                                            +   name                     :   java.lang.String
                  +   add ()              :   void                                                                                   +   description              :   java.lang.String
                  +   remove ()           :   void
                                                                                           1
                                                                                               0..*
                                  1                                            CaseComment
                                                                   +   caseCommentId       :   int
                          0..*                                     +   case                :   Case
                                                                   +   rule                :   Rule
                                                                   +   type                :   java.lang.String
                      CaseContact                                  +   document            :   Document
   +    caseContactId                 :   int                      +   commentDate         :   java.util.Date
   +    case                          :   Case                     +   comment             :   java.lang.String
   +    organization                  :   Organization             +   issue               :   java.lang.String               0..*
   +    contact                       :   Contact                  +   contact             :   Contact
   +    comments                      :   java.lang.String         +   nextComment         :   CaseComment
                                                                                                                                          CaseDocument
   +    type                          :   java.lang.String         +   prevComment         :   CaseComment
   +    email                         :   EmailAddress                                                                    + caseDocumentId : int
   +    phone                         :   PhoneNumber                                                                     + document       : Document
   +    address                       :   PostalAddress                                                                   + type           : java.lang.String
   +    preference                    :   java.lang.String
   +    preferenceDescription         :   java.lang.String




                                                Figure 4: Case management module object model



Version 1.1                                                                                                           9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                                             Resource Data, Inc
                                                                                         27
Resource Authorization System (RAS)
System Design


     5.2.1.3.    Integration
Modules and systems that rely on the case management module
         Projects sub-module
         Actions sub-module
         Clock sub-module
         Milestones sub-module
         LAS Case Management
Modules and systems that the case management module relies on
         Documents module
         Contacts module
         Application module
         Rules module
         Location module
         LAS Revenue and Billing
         Credit card system
The following diagram describes the API interface that will be supported for the Case
module, including sub-modules.
                                                  CaseAPI


                                    + getCase (int caseId) : Case
                                    + searchCases ()       : Collection


Additionally, the Case module will have a CaseInterop object to support integration with the
LAS Case Management system. The complete description of the methods represented here
can be found in the external interfaces section.
                                                CaseInterop


                                      +   reportVisitorCount ()   :   void
                                      +   feeReceived ()          :   void
                                      +   cashBondReceived ()     :   void
                                      +   flagCase ()             :   void


     5.2.1.4.    Presentation
Following is the list of screens included in the Case module. For complete descriptions of
screen types and navigation, please refer to the Screen Prototypes document (Deliverable
2.3) located at www.resdat.com/dnr/deliverables.
                    Screen                                                          Type

Version 1.1                                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                    Resource Data, Inc
                                                   28
Resource Authorization System (RAS)
System Design


Search cases                                      Query
New case                                          Wizard
Case details                                      Detail navigation
Project details                                   Detail
Documents                                         Detail navigation
Add case note                                     Detail
Research                                          Other
Land management documents                         Other
Applicant history                                 Detail
Comments                                          Detail
Respond to comment                                Detail
Distribution lists                                Detail

     5.2.1.5.     Reports
The following reports are included in this module:
         Project Detail Report
         Project Data Sheet
         Case Summary Report
         Case Milestones
         Action Report
         Case Status
         Case Timeline (graphical)
         Stipulation and Enforceable Policy Usage
         Case Detail History
         Case Transaction Report
         Customer/Contact List
         Stipulation Report
         Plat Print-out
         Case Comments Report
         Case Performance Metrics
         Workload

Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                             29
Resource Authorization System (RAS)
System Design


         ―Clock‖ Report
         Case Statistics Report

     5.2.1.6.    Ad-hoc Reporting
DNR must have the ability to query and report on data in an ad-hoc fashion. The Case
module will include an ad-hoc reporting component. This component will consist of
specialized database views and a user interface.
Database views will be created for the groups of data required most by DNR staff. Initially
this will consist of Cases, Projects, and Contacts. The views will basically represent the core
entities (CASE, PROJECT, LAND_USE, CONSISTENCY_REVIEW,
COMMERCIAL_REC, and CONTACT) and related entities in a denormalized reporting
table.
The user interface will be designed to query the Oracle metadata and present the columns to
the user. Users will be able to specify custom filter criteria for any of the columns in the
view; specify which columns are visible in the report and a column header for the report;
and, specify a sort order for the results. The results will be presented on a separate web page
and can be saved as an external document, like Microsoft Excel. The user will also be able to
save the report criteria and run the report at a later date. The report criteria, or query, will
include the columns selected, the headers, the filter criteria, and the sorting order. The user
will also be able to add a description of the query and can make it a public query so that other
users will have access to it.
Additional user input and design may be required to clearly define the related entities
required in the view.

     5.2.2. Project Sub-Module
An important part of case management is the ability to organize and group cases in a larger
context. The project sub-module provides this capability. A project is defined as the activity
the customer is engaged in. As such, it may or may not have one or more cases associated
with it, depending on the nature of the activity, the location, and the current regulations.
Projects are categorized by broad categories – mining, oil and gas, etc. – and can be used to
record notes, identify areas of activity or potential activity (location), and can be used to
organize contacts associated with the project. Additionally, a project may be funded by a
grant and there is a link to the grants module.




Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                             30
Resource Authorization System (RAS)
System Design



                                       Case         Milestones

                                  Clock                 Actions


                                          Project

                            Contacts                      Grants

                            Documents                   Location


                                 Figure 5 - Project Sub-Module

     5.2.2.1.   Database
                  Table name                                         Topic area

PROJECT                                             Projects
PROJECT_CATEGORY                                    Projects
PROJECT_CONTACT                                     Projects
PROJECT_CONTACT_TYPE                                Projects
PROJECT_DOCUMENTS_XREF                              Projects
PROJECT_NOTE                                        Projects
CATEGORY                                            Projects
RELATED_PROJECT                                     Projects
RELATED_PROJECT_TYPE                                Projects
EXTERNAL_CASE                                       Projects


     5.2.2.2.   Business logic
This module covers the following use cases:
                Use cases                                           Use cases

2.6 Record pre-application interview               2.43 Start a new case from an
                                                   application

Version 1.1                                                    9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                      Resource Data, Inc
                                              31
Resource Authorization System (RAS)
System Design


2.7 Create a new project                        2.44 Record project notes
2.8 Add a case to a project                     2.45 Merge projects
2.40 Record external cases                      4.4 Show projects in an area
2.42 Start a new case from an existing          4.5 Access project map
case
The following object model represents the implementation of the necessary business logic for
the projects sub-module.




Version 1.1                                               9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                 Resource Data, Inc
                                           32
Resource Authorization System (RAS)
System Design

                                                                             Project
                                                +   projectId         :   int
                                                +   label             :   java.lang.String
                                                +   description       :   java.lang.String
                                                +   initiateDate      :   java.util.Date
                                                +   projectContacts   :   Collection
                                                +   projectNotes      :   Collection
                                                +   externalCases     :   Collection
                                                +   relatedProjects   :   Collection
                                                +   cases             :   Collection
                                                +   categories        :   Collection
                                                +   locations         :   Collection
                                                +   newProject (Location location)                :   Project
                                                +   newProject (Case case)                        :   Project
                                                +   mergeProject (Project srcProject)             :   Project
                                                +   addRelatedProject ()                          :   RelatedProject
                                                +   addContact ()                                 :   ProjectContact
                                                +   addProjectNote (ProjectNote note)             :   void
                                                +   addExternalCase ()                            :   ExternalCase
                                                +   addCategory ()                                :   void
                                                +   addCase (Case case)                           :   void
                                                +   removeRelatedProject ()                       :   void
                                                +   removeContact ()                              :   void
                                                +   removeExternalCase ()                         :   void
                                                +   removeCategory ()                             :   void
                                                +   addLocation ()                                :   Location
                                                +   removeLocation ()                             :   void
                                         0..1   +   getProjectCases ()                            :   Cases

                                                                                                                            0..1
                                                       0..1                         0..1


                                                                                                               0..*
                                                                                                                                    ExternalCase
                                                                                                                 +        externalCaseId      :   int
                  RelatedProject                                                                                 +        projectId           :   int
    +   relatedProjectId     :   int                                                                             +        name                :   java.lang.String
    +   relatedProject       :   Project                                                                         +        description         :   java.lang.String
                                                       0..*
    +   relatedProjectType   :   java.lang.String                                                                +        ownerOrg            :   Organization
    +   notes                :   java.lang.String                                                                +        urlLink             :   java.lang.String
    +   prevRelatedProject   :   Project                                                                         +        prevExternalCase    :   ExternalCase
    +   nextRelatedProject   :   Project                                                                         +        nextExternalCase    :   ExternalCase




                                                                                       0..*

                                                0..*
                  ProjectContact                                                                                                ProjectNote

   +    projectContactId     :   int                                                          +   projectNoteId       :   int
   +    contact              :   Contact                                                      +   projectId           :   int
   +    projectContactType   :   java.lang.String                                             +   author              :   Contact
   +    comments             :   int                                                          +   note                :   java.lang.String
   +    prevContact          :   ProjectContact                                               +   type                :   java.lang.String
   +    nextContact          :   ProjectContact                                               +   prevNote            :   ProjectNote
                                                                                              +   nextNote            :   ProjectNote
                                                                                              + newProjectNote (java.lang.String noteType) : ProjectNote


                                           Figure 6: Project sub-module object model

       5.2.2.3.        Integration
Modules and systems that rely on the projects sub-module
           Case module
           Actions sub-module

Version 1.1                                                                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                                    Resource Data, Inc
                                                                             33
Resource Authorization System (RAS)
System Design


         Clock sub-module
         Milestones sub-module
Modules and systems that the projects sub-module relies on
         Documents module
         Contacts module
         Grants module
         Rules module
         Location module

     5.2.2.4.      Presentation
Following is the list of screens included in the project sub-module.
                       Screen                                             Type

Search projects                                       Query
Project details                                       Detail navigation
New project                                           Wizard
Merge projects                                        Wizard
Cases                                                 Detail
External cases                                        Detail
Add external case                                     Detail
Project notes                                         Detail
Contacts                                              Detail navigation
Add contact                                           Query
Pre-application interview                             Detail


     5.2.3. Milestone Sub-Module
At the beginning of the case, the milestones defined lay out the road the case will follow. As
the case is processed and milestones are completed, milestones can be used to analyze case
processing history.
The following is the RAS definition of milestones:
               A milestone is a point on the timeline that may or may not be predefined. The
                case milestone list represents the temporal progress of the case at the given date
               A milestone may or may not have relationships to milestones before and after it

Version 1.1                                                       9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                         Resource Data, Inc
                                                 34
Resource Authorization System (RAS)
System Design


               A phase is represented as the distance between two milestones (range). A phase
                may or may not have a specified duration. The same phase can apply to multiple
                ranges
               Milestones are completed, or achieved, by taking an action. Some milestones are
                changeable by the user, while some are not. When a milestone is modified, an
                action is recorded registering the change
               If an action repeats a previously completed milestone, all subsequent milestones
                must be repeated (e.g. the relationship between milestones is constant)



                                        Project          Case

                                     Clock                 Actions


                                         Milestones

                                    Figure 7 - Milestones sub-module

     5.2.3.1.      Database
The following tables are used in the Milestones sub-module
                      Table name                                       Topic area

CASE_MILESTONE                                         Case Milestones
RELATED_CASE_MILESTONE                                 Case Milestones
TIME_UNIT                                              Case Milestones
PHASE                                                  Case Milestones

     5.2.3.2.      Business logic
Milestones will be implemented as a directed graph data structure – milestone will represent
vertices and the range between milestones will represent the edges. The edges may or not be
weighted, depending on whether a range amount has been specified or if just a relationship
has been specified between two milestones. Additionally, any range can have a phase
attributed to it. The phase will provide the link between the milestones and clocks and
actions.
This type of data structure accurately models the nature of milestones and their relationships
to each other. It will allow RAS to support fairly complex paths through the milestones as
well as position the system well for future enhancements.

Version 1.1                                                     9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                       Resource Data, Inc
                                                  35
Resource Authorization System (RAS)
System Design




                     M1             M2             M3            M4            M8



                               M5             M6          M7



                                         M9


                                  Figure 8 - Milestone graph
As modeled in the object model, each range (edge) can be weighted or have a time unit
associated with the range. In order to allow for accurate comparisons and calculations of
time, a time unit object is added to provide representation for an absolute time unit. This will
be a configurable value, but will be set to hours by default. Within the MilestoneGraph
object, methods are provided to calculate elapsed time for a given phase both total time
(gross) and time the clock was on (net).
When a case is first initiated from a template, a default set of milestones is created for the
case, based on the case type template. (See the Administration module for more on case type
templates.) These default milestones will establish the phases for the case; actions will be
used to complete these milestones.




Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                              36
Resource Authorization System (RAS)
System Design


                                                                                     MilestoneGraph
                                                                  + milestoneCount : int
                                                                  + case           : Case
                                                                  +   addMilestone ()                                :   void
                                                                  +   addPhase ()                                    :   void
                                                                  +   addRange ()                                    :   void
                                                                  +   removeMilestone ()                             :   void
                                                                  +   removePhase ()                                 :   void
                                                                  +   removeRange ()                                 :   void
                                                                  +   getPhaseMilestones ()                          :   Collection
                                                                  +   getPhaseTimeNet ()                             :   int
                                                                  +   getPhaseTimeGross ()                           :   int
                                                                  +   acheiveMilestone (Milestone ms)                :   void


                                                                                    1                        1

                                                                                                                                      Milestone
                                                                                                                 +       milestoneId       :   int
                                                                                                                 +       name              :   java.lang.String
                                                                                                                 +       description       :   java.lang.String
                                                                                                                 +       date              :   java.util.Date
                                                                                                                 +       inCount           :   int
                                                     Range                                                       +       outCount          :   int
         TimeUnit                                                                  0..*               0..*
                                        +   soureMilestone    :   Milestone                                      +       notification      :   Notification
+ timeUnitId   : int                    +   targetMilestone   :   Milestone                                      +       clockImpactList   :   Collection
+ unit         : int                    +   range             :   int                                            +       profileList       :   Collection
+ absoluteUnit : int                    +   timeUnit          :   TimeUnit                                       +       getProjectedDate ()       :   java.util.Date
                                        +   phase             :   Phase                                          +       isAdjacent ()             :   boolean
                                        +   clock             :   Clock                                          +       addInCount ()             :   int
                                        + getAbsoluteRange () : int                                              +       subtractInCount ()        :   int
                                                                                                                 +       addOutCount ()            :   int
                                                                                                                 +       subtractOutCount ()       :   int
                                                                                                                 +       updateNotification ()     :   void
                                                                                                                 +       removeNotification ()     :   void
                                                                                                                 +       addNotification ()        :   void


                                                                                                                                                       0..1
                                                                                                                                                       0..*
                    Phase                                                                 Clock
     + phaseId     : int                                               +    clockId       :   int                                              ClockImpact
     + name        : java.lang.String                                  +    clockName     :   java.lang.String
     + description : java.lang.String                                                                                                  + clock : Clock
                                                                       +    description   :   java.lang.String
                                                                                                                                       + state : boolean
                                                                       +    clockState    :   int
                                                                       + startClock () : void
                                                                       + stopClock () : void


                                Figure 9: Milestones sub-module object model

     5.2.3.3.          Integration
Modules and systems that rely on the Milestones sub-module
           Case sub-module
           Actions sub-module
           Clock sub-module
Modules and systems that the Milestones sub-module relies on
           Clock sub-module

Version 1.1                                                                                        9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                          Resource Data, Inc
                                                                       37
Resource Authorization System (RAS)
System Design


     5.2.3.4.      Presentation
Most of the screens for this sub-module are tightly integrated with the overall Case
Management module. The following screens will be most involved with Milestones.
                       Screen                                              Type

Add case trigger                                       Detail
Milestones                                             Detail navigation
Add case action                                        Wizard

     5.2.4. Action Sub-module
If the case management module is the heart of RAS, actions are the chambers pumping blood
through the system. Actions are predefined types of events that are recorded as taking place
at a given point of time by an individual. The case is controlled through a series of actions
initiated by users. All actions are logged as the case is processed, and can be displayed
chronologically to show the processing of the case. An action can do one or more of the
following:
               Achieve a milestone
               Change the status of the case
               Send notifications to contacts
               Schedule triggers
               Create and store documents in the repository
               Record any event related to a case



                                        Project           Milestones

                                    Clock                        Case


                                            Actions

                            Documents                           Contacts


                                    Figure 10 - Action Sub-Module



Version 1.1                                                        9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                          Resource Data, Inc
                                                  38
Resource Authorization System (RAS)
System Design


     5.2.4.1.     Database
                     Table name                                               Topic area

CASE_ACTION                                                  Case Actions
CASE_ACTION_DOCUMENT_XREF                                    Case Actions
CASE_ACTION_TYPE                                             Case Actions
CASE_ACTION_TYPE_DOC_XREF                                    Case Actions
CASE_ACTION_TYPE_MILESTONE_XREF Case Actions
CASE_ACTION_TYPE_PHASE_XREF                                  Case Actions
LAS_ACTION_TYPE                                              Case Actions

    5.2.4.2.   Business logic
When a new case is started, a new set of action types are created and associated with the case
based on the case type template. (See the Administration module for more on case type
templates.) An action type can be thought of as a template for an action. The action type may
specify document templates the user must complete, and action types will be assigned a
phase or phases they are valid for – if the case isn‘t in that phase, the user will not be able to
take an action of that type. Additionally, action types may be linked to specific milestones of
the case (based on the case default milestones) or may add new milestones and corresponding
notifications.
An action is the instance of the action type; it is created when the user records an action of a
specific action type. Beyond what is specified in the action type, the action can have
additional documents associated with it, can send notifications to a selected distribution list,
or change the status.
Actions are implemented using the Command pattern from the well-known ―Gang of Four‖
Design Patterns1. There is an abstract Step class and a family of subclasses representing each
possible step that can be performed by an action (complete a milestone, change status, send
notifications, etc.). The Step class defines an unimplemented perform method; the subclass
for each type of step will implement the perform method.
Actions are a critical part of RAS being able to process a case. The design allows
administrators to configure action types with several different attributes. However, actions
are so central to case processing that the design must allow for unanticipated action types that
need to do things not supported in the current design. In order to allow maximum flexibility
without significant design, we have added a set of ―hooks‖ to each action. Each step contains
a set of hooks (pre and post hooks) which will be executed when the action is performed. The
hooks will be configured using an XML config file based on the following format:
          <action-steps>


1
 Gamma E, Helm R, Johnson R, Vlissides J. Design Patterns: Element of Reusable Object-Oriented Software; Addison-
Wesley, 1995.
Version 1.1                                                             9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                               Resource Data, Inc
                                                      39
Resource Authorization System (RAS)
System Design


                <completeMilestone prePerform=”us.ak.state.dnr.ras.actions.A”
                postPerform=”us.ak.state.dnr.ras.actions.B”/>
                <sendNotifications prePerform=”us.ak.state.dnr.ras.actions.C”
                postPerform=”us.ak.state.dnr.ras.actions.D”/>
          </action-steps>
A developer would use these hooks to call out to additional functionality not provided in the
current implementation of RAS. Steps are queued as actions needing them are created by
users and their perform methods called polymorphically when triggered through the user
interface.




Version 1.1                                                9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                  Resource Data, Inc
                                            40
Resource Authorization System (RAS)
System Design

                                                              CaseAction                                                 ActionType
       CaseActions
                                                +   caseActionId        : int                             +   name                : java.lang.String
                                                +   takenBy             : Contact                         +   lasActionTypeCode   : java.lang.String
   +    sort ()     : int                       +   actionType          : ActionType                      +   description         : java.lang.String
   +    filter ()   : int     0..1     0..*     +   date                : java.util.Date                  +   phase               : Phase
   +    find ()     : int                       +   description         : java.lang.String                +   milestones          : MilestoneGraph
   +    add ()      : int                       +   case                : Case                            +   docList             : Collection
   +    remove ()   : int                       +   lasActionCode       : java.lang.String
                                                +   actionDocuments     : Collection                      + updateStatus () : void

                                                + perform () : void
                                                                                                                                     0..1
                                                                                                                                     0..*


                                                                                                                          ActionTypeDocs
                                                                                   Step                             + actionType  : ActionType
                                                                                          {abstract}                + docTemplate : Document
                                                                                                                    + autoSave    : boolean

                                                                         + prePerform () : void
                                                                         + perform ()     : void
                                                                         + postPerform () : void




                                        CompleteMilestoneStep                                     ChangeStatusStep


                                         + prePerform () : void                                + prePerform () : void
                                         + perform ()     : void                               + perform ()     : void
                                         + postPerform () : void                               + postPerform () : void
              complete


                                                           send                                           change
           MilestoneX                                                                                                             send

                                     completePhase
       + complete () : void                                                                                                   NotificationZ
                                                                                                          StatusZ

                            CaseX                     NotificationX                                                         + send () : void
                                                                                                  + change () : void

              + completePhase () : void              + send () : void


                                                       SendNotificationsStep          ScheduleTriggerStep


                                                      + prePerform () : void         + prePerform () : void
                                                      + perform ()     : void        + perform ()     : void
                                                      + postPerform () : void        + postPerform () : void


                                                                  change                       schedule


                                                            NotificationY                     TriggerY


                                                          + send () : void             + schedule () : void


                                              Figure 11: Actions sub-module object model




Version 1.1                                                                                            9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                              Resource Data, Inc
                                                                           41
Resource Authorization System (RAS)
System Design


     5.2.4.3.   Integration
Action types can have a corresponding LAS action type so that any time an action of a
specific type is added to the case, a corresponding LAS action type is sent to LAS with the
standard parameters. The Case module integration object models contain functionality for
this sub-module, as well.

     5.2.4.4.   Presentation
The only user interface for the Action sub-module is the case action wizard. Each action a
user takes will be defined by an action type, and will have a certain number of pre-configured
steps the user must take to complete the action. The wizard will be dynamically configured
based on the action type taken; however, it will also allow users to add properties to the
action outside of the pre-configured settings.


                   Screen                                            Type

Add case action                                  Wizard

     5.2.5. Clock Sub-module
Certain case types in RAS rely heavily on the concept of a clock – rules about when the clock
is running, when it isn‘t, when it starts, and when it stops. The Clocks sub-module is made up
of rules defining the temporal relationships between milestones at a given time or
historically.

     5.2.5.1.   Database
                 Table name                                      Topic area

CLOCK                                            Clocks
CLOCK_IMPACT                                     Clocks

     5.2.5.2.   Business Logic
                Use cases                                         Use cases

12.5 Start clock                                   12.6 Stop clock

     5.2.5.3.   Presentation
The Clocks sub-module user interface is actually embodied in the interfaces for the Actions
and Milestones sub-modules. Clocks are started or stopped by achieving milestones, and are
accessed through the case timeline.




Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                            42
Resource Authorization System (RAS)
System Design


5.3.      Contacts module
The Contacts module represents a robust contact management system, and will contain the
contact information for all RAS stakeholders, including users, customers, contacts, DNR
employees, other state and federal employees, and anybody who has contact with RAS. A
contact is any person involved with DNR in some manner
The module supports assigning people to various organizations in various roles, both of
which may change over time. It also supports the concept that an individual may interact
with RAS while acting in a variety of roles and that, from a system perspective, the way we
treat the individual will change depending on what role an individual is fulfilling during a
given contact with RAS.
Contacts are referenced in several other areas of RAS – projects, cases, grants, etc. The
contacts module will provide an interface (API) to allow other RAS areas to use contacts in a
consistent and straightforward manner. This design also facilitates future expansion by
allowing other systems to access contacts through a single interface.


                            Notifications            Distribution Lists


                                      Contacts

               Case                       Security                          Grants

                              Rules                      Location


                                            Contacts module
                                 Figure 12: LAS

     5.3.1.1.   Database
The database component of the contacts module primarily consists of the tables in the
Contacts topic area of the physical data model. The list of specific tables used in this module
is listed below.

                Table name                                       Topic area

CONTACT                                           Contacts
CONTACT_COMMENT                                   Contacts
ADDRESS                                           Contacts
ADDRESS_TYPE                                      Contacts
Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                             43
Resource Authorization System (RAS)
System Design


ORGANIZATION                                      Contacts
ORGANIZATION_MEMBER                               Contacts
ORGANIZATION_MEMBER_TYPE                          Contacts
ORGANIZATION_TYPE                                 Contacts
COMMUNICATION_METHOD                              Contacts
COMMUNICATION_METHOD_TYPE                         Contacts
EMAIL                                             Contacts
EMAIL_TYPE                                        Contacts
PHONE                                             Contacts
PHONE_TYPE                                        Contacts
                            Table 1: Contacts module database tables

     5.3.1.2.   Business logic
The following use cases are covered in the Contacts module:
                Use cases                                          Use cases

7.1 Add contact                                     7.6 Update organization
7.2 Update contact                                  7.7 Delete organization
7.3 Inactivate contact                              7.8 Synchronize contacts
7.4 Activate contact                                7.9 Deactivate organization
7.5 Add organization




Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                             44
Resource Authorization System (RAS)
System Design

                                                                             Organization
                                                       +     organizationId         :   int                                                                OrganizationType
                                                       +     organizationType       :   OrganizationType                                           + organizationTypeId : int
                                                                                                                          1
                                                       +     name                   :   java.lang.String                                           + label              : int
                                                       +     description            :   java.lang.String                            1
                                                                                                                                                   + description        : int
                                                       +     cid                    :   int
                                                       +     ein                    :   int
                                                       +     memberships            :   Collection
                                                       + activateOrg ()   : void
                                                       + inactivateOrg () : void


                                                                                    1
                      Membership
                                                                                                                                 CommunicationMethod
    +       membershipID       :   int
                                                                                                                 + communicationMethodId : int
    +       organization       :   Organization
                                                                                                                 + label                 : java.lang.String
    +       contact            :   Contact
                                                                                                                 + description           : java.lang.String
    +       type               :   java.lang.String
                                                             1..*
    +       typeDescription    :   java.lang.String
    +       activeDate         :   java.util.Date
    +       inactiveDate       :   java.util.Date
                                                        0..*                                                                                        0..*
    + activateMembership ()   : void
    + inactivateMembership () : void

                                                                                                                 1


                                                                                                         Contact
                                                                                +   contactId                         :   int
                   EmailAddress                                                 +   userId                            :   int
                                                                                +   lastName                          :   java.lang.String
   +    emailId           :   int                                               +   firstName                         :   java.lang.String
                                                                         1
   +    contactId         :   int                                               +   middleName                        :   java.lang.String
   +    emailType         :   java.lang.String                                  +   activeDate                        :   java.util.Date
   +    emailAddress      :   java.lang.String                           1      +   inactiveDate                      :   java.util.Date
                                                      0..*
   +    comment           :   java.lang.String                                  +   cid                               :   java.lang.String
   +    activeDate        :   java.util.Date                                    +   emailAddresses                    :   Collection
   +    inactiveDate      :   java.util.Date                             1      +   phoneNumbers                      :   Collection
   + activateEmail ()   : void                                                  +   postalAdresses                    :   Collection
   + inactivateEmail () : void                                                  +   communicationMethods              :   Collection
                                                                                +   comments                          :   Collection
                                                                                +   activateContact ()       :   void
                                                                                +   inactivateContact ()     :   void
                                                                                +   getHistory ()            :   ContactHistory
                                                                                +   synchContact ()          :   void


                                                                                                  1                                     1
                      PostalAddress                                                                                                         0..*
        +    addressId         :   int
        +    contactId         :   int                                                                                                      ContactComment
        +    addressType       :   java.lang.String
        +    streetAddress     :   java.lang.String                                                                             + commentId : int
                                                           0..*                                   0..*
        +    streetAddress2    :   java.lang.String                                                                             + contactId : int
        +    suite             :   java.lang.String                                                                             + comment   : java.lang.String
        +    city              :   java.lang.String                                     PhoneNumber
        +    state             :   java.lang.String                  +       phoneId          :   int
        +    zip               :   java.lang.String                  +       phoneType        :   java.lang.String
        +    comment           :   java.lang.String                  +       contactId        :   int
        +    activeDate        :   java.util.Date                    +       phoneNumber      :   java.lang.String
        +    inactiveDate      :   java.util.Date                    +       comment          :   java.lang.String                                     ContactHistory
        + activateAddresss () : void                                 +       activeDate       :   java.util.Date                        + caseList    : Hashtable
        + inactivateAddress () : void                                +       inactiveDate     :   java.util.Date                        + projectList : Hashtable
                                                                     + activatePhone ()   : void                                        + getFinancialStatus () : void
                                                                     + inactivatePhone () : void


                                                 Figure 13: Contacts module class diagram



Version 1.1                                                                                                          9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                                            Resource Data, Inc
                                                                                        45
Resource Authorization System (RAS)
System Design


     5.3.1.3.     Integration
Modules and systems that rely on the Contacts module
         Notifications sub-module
         Distribution lists sub-module
         Case module
         Security module
         Grants module
         Rules module
         Location module
         LAS Customer Information System (CIS)
Modules and systems that the Contacts module relies on
         LAS Customer Information System (CIS)
The following diagram describes the API interface that will be supported for the Contacts
module.
                                                  ContactsAPI


                                     +   GetContact ()       :   Contact
                                     +   GetOrg ()           :   Organization
                                     +   GetOrgContacts ()   :   Contact
                                     +   GetOrgRoles ()      :   Contact
                                     +   SearchContacts ()   :   Contact[]
                                     +   SearchOrgs ()       :   Organization[]


                              Figure 14: Contacts module API diagram

     5.3.1.4.     Presentation
                     Screen                                                        Type

Search organizations                                   Query
New organization                                       Detail
Organization details                                   Detail
Search contacts                                        Query
New contact                                            Detail
Contact details                                        Detail




Version 1.1                                                                9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                  Resource Data, Inc
                                                  46
Resource Authorization System (RAS)
System Design


     5.3.1.5.    Reports
The following reports are included in this module:
         Project Information Distribution Lists
         Case Distribution Lists
         Client Information Report
         Contact List

     5.3.2. Notifications sub-module
The notifications sub-module provides the capability for RAS to send notifications via email
or printed letters (for those without email access). This sub-module acts as a centralized
utility providing the notifications services needed in RAS. In RAS, notifications are created
in two ways – either they are sent immediately in response to a user-initiated event (i.e. an
action); or, they are schedule to be sent based on a case milestone (i.e. case trigger).
Notifications are scheduled using milestones on the case timeline. Each milestone may have
a list of case contacts or distribution lists associated with it that require a notification when
the milestone is reached, or at a given amount of time before the milestone is scheduled to be
reached. A system process will run automatically at a configurable interval, scanning the list
of milestones. When a milestone is reached, any notifications associated with it will be
generated and sent.
A notification sent to the notifications sub-module will be fulfilled in one of two ways based
on the preferences of the notification contact. The first method will be a system generated
email. This email will be a plain text email, but may include associated documents as
attachments to the email. Within the email message, the sender listed will be the user that
scheduled the notification. Any errors or problems delivering the email message will be
handled through standard email protocols, typically directing errors back to the sender. This
will also allow recipients to use the reply feature of their email program to respond to the
email.
The second notification method will be a printed letter. This feature will be used when an
email address is not present or the contact has specified printed information as the preferred
communication method. As necessary, a DNR user will receive a report of any notifications
that they have initiated that must be printed manually. The user may then use that list to print
notification letters and any supporting documents needed to send to the contact.




Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                              47
Resource Authorization System (RAS)
System Design




                                 Contacts                Distribution Lists


                                    Notifications

                               Figure 15: Notifications sub-module

     5.3.2.1.   Database
                 Table name                                              Topic area

MILESTONE_NOTIFY                                      Milestones

     5.3.2.2.   Business logic
The Notifications sub-module supports the following use cases.
                Use cases                                                 Use cases

12.1 Send a notification                                12.3 Update a scheduled notification
12.2 Schedule a notification                            12.4 Delete a notification
The following is the object model for the notifications service.
                                              Notification
                                     + notificationId : int
                                     + contacts       : Collection
                                     + sendEmail () : void
                                     + printLetter () : void


                           Figure 16: Notifications module object model

     5.3.2.3.   Integration
This design is based on the understanding we will be integrating with iPlanet Messaging
Server 5.2, as specified in the RAS IT Requirements document (Deliverable 1.5) located at
www.resdat.com/dnr/deliverables. This system will only be used to send outgoing mail.

     5.3.2.4.   Presentation
This sub-module is used primarily by other modules. The only user interface will be a screen
displaying notifications that must be delivered in a format other than email.
                   Screen                                                    Type

Pending notifications                                 Query


Version 1.1                                                          9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                            Resource Data, Inc
                                                 48
Resource Authorization System (RAS)
System Design


     5.3.3. Distribution lists sub-module
The Distribution lists sub-module is used for organizing contacts. Distribution lists are used
to send notices or updates to a group of contacts during case processing or adjudication.
Individual DNR staff also use distribution lists to keep ―frequently used‖ contact lists for
reference.


                              Notifications                Contacts


                                Distribution Lists
                                 Case                     Security


     5.3.3.1.   Database
                 Table name                                         Topic area

DISTRIBUTION_LIST                                  Distribution Lists
DISTRIBUTION_LIST_MEMBER                           Distribution Lists

     5.3.3.2.   Business logic
The following use cases are covered in the Distribution lists sub-module:
                Use cases                                            Use cases

2.18 Modify distribution list                        2.20 Create and post public notice
2.19 Send out review packets




Version 1.1                                                     9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                       Resource Data, Inc
                                              49
Resource Authorization System (RAS)
System Design


                                                   DistributionList
                              +   distributionListId   :   int
                              +   name                 :   java.lang.String
                              +   description          :   java.lang.String
                              +   owner                :   Contact
                              +   case                 :   Case
                              + sendNotification (Notification notification) : void


                                                                 0..1


                                                       0..*


                                              DistributionListMember
                                         + contact      : Contact
                                         + activeDate   : java.util.Date
                                         + inactiveDate : java.util.Date
                                         + activateMember ()   : void
                                         + inactivateMember () : void


     5.3.3.3.   Integration
Modules and systems that rely on the Distribution list sub-module
         Case module
Modules and systems that the Distribution list sub-module relies on
         Security module

     5.3.3.4.   Presentation
                     Screen                                                           Type

Distribution lists                                              Detail
Modify distribution list                                        Detail

5.4.      Location module
Location plays a key role in RAS, and the Location module is designed as the single interface
and storage for all geospatial information required by the different RAS components. The
RAS Location module actually becomes a thin wrapping around an existing GIS system.
Locations are stored in the module by associating a unique id with a spatial object stored in
the GIS system, and then using that unique id as a reference for the other RAS modules. This
module will also provide services like translating non-graphical locations to graphical
locations or translating non-graphical locations from one format to another.




Version 1.1                                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                     Resource Data, Inc
                                                           50
Resource Authorization System (RAS)
System Design




                                      Location

                Documents               Application                     Contacts

                              Case                            Rules



     5.4.1.1.    Database


                  Table name                                       Topic area

LOCATION                                          Locations
LOCATION_TYPE                                     Locations
LOCATION_PROJECT_XREF                             Locations
LOCATION_CONTACT                                  Locations
LOCATION_CONTACT_TYPE                             Locations
LOCATION_DOCUMENTS_XREF                           Locations

     5.4.1.2.    Business logic
                 Use cases                                          Use cases

4.1 Create graphical location                       4.5 Access project map
4.2 Get areas of concern                            4.6 Show area activity
4.3 Define area of interest                         4.7 Check location overlap
4.4 Show projects in an area                        4.8 Create non-graphical location


A large part of the functionality of this module lies in the GIS system – the RAS logic relates
locations to other entities within RAS.




Version 1.1                                                    9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                      Resource Data, Inc
                                             51
Resource Authorization System (RAS)
System Design


                                                Location
                                 +   locationId       :   int
                                 +   type             :   java.lang.String
                                 +   geoDbObjectId    :   int
                                 +   name             :   java.lang.String
                                 +   description      :   java.lang.String
                                 +   projectList      :   Collection
                                 +   contactList      :   Collection
                                 +   docList          :   Collection
                                 +   addContact ()    : void
                                 +   removeContact () : void
                                 +   addDoc ()        : void
                                 +   removeDoc ()     : void


     5.4.1.3.     Integration
Modules and systems that rely on the Location module
         Case module
         Documents module
         Application module
         Contacts module
         Rules module
Modules and systems that the Location module relies on
         GIS Application

     5.4.1.4.     Presentation
                     Screen                                                      Type

Select location                                       Other
Location details                                      Other

5.5.      Documents module
Documents, document storage, and document creation are required components of RAS, and
are an integral part of the functionality required in several other modules. The documents
module describes a RAS document including metadata about the document, keywords, and
document versions. This module provides the mechanism to relate documents to entities
within RAS in meaningful ways. The figure below (Figure 17: Documents module) shows
the relationship of the documents module to the sub-modules and components of RAS.
The different entities that use RAS documents are:
    Projects
    Cases
    Locations

Version 1.1                                                              9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                Resource Data, Inc
                                                 52
Resource Authorization System (RAS)
System Design


         Case actions
         Grants
         Application
This module also contains two sub-modules – the document repository sub-module and the
document templates sub-module. Modules that use the document repository will link
documents via a cross-reference table. In this manner, additional information about the
document, specific only to that module, can be stored about the document.
The document repository provides storage and retrieval of RAS documents. Since each
document stored in the repository has basic metadata (document name, description, creation
date, author, etc.) as well as keywords, the repository provides an interface to search these
documents and allow users access to documents. Modules that use the document repository
are:
         Case module
         Location module
         Contacts module
         Application module
         Grants module
Finally, the document templates sub-module provides the functionality for users to generate
standard documents based on templates merged with system data. The design presented here
includes a syntax and structure for creating a document that the system will be able to
populate with data.


                               Templates              Repository


                                   Documents

                    Case                   Location                Contacts

                            Application                Grants


                                Figure 17: Documents module




Version 1.1                                                 9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                   Resource Data, Inc
                                             53
Resource Authorization System (RAS)
System Design


     5.5.1.1.   Database
                 Table name                                Topic area

DOCUMENT                                   Documents
DOCUMENT_KEYWORD                           Documents
KEYWORD                                    Documents


     5.5.1.2.   Business logic
                Use cases                                   Use cases

11.1 Update document                         11.3 Add document
11.2 Delete document




Version 1.1                                            9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                              Resource Data, Inc
                                      54
Resource Authorization System (RAS)
System Design


                                       DocumentRepository


              +   searchDocs ()                                         :   Collection
              +   addDoc ()                                             :   int
              +   removeDoc ()                                          :   int
              +   updateDoc ()                                          :   int               0..1
              +   getDoc (int docId)                                    :   Document
              +   getDocVersion (int docId, int versionId)              :   Document
              +   newDocument (java.lang.String name)                   :   Document
              +   addDocument (Document doc)                            :   void
              +   mergeDocument (Document template, boolean autoSave)   :   Document

                                                                                                   0..*


                                                                                          Document
                                                                        +    docId             :   int
                                                                        +    fileType          :   java.lang.String
                                                                        +    contact           :   Contact
                                                                        +    docType           :   java.lang.String
                                                                        +    name              :   java.lang.String
                                                                        +    description       :   java.lang.String
                                                                        +    createDate        :   java.util.Date
                                                                        +    docVersionList    :   Collection
                                                                        +    docKeywords       :   Collection




                                                                                         DocumentRevision
                                                                             +   docRevisionId      :   int
                                                                             +   note               :   java.lang.String
                                                                             +   revision           :   java.lang.String
                                                                             +   path               :   java.lang.String
                                                                             +   revisionDate       :   java.util.Date



                                  Figure 18: Documents module object model

     5.5.1.3.         Integration
Modules and systems that rely on the Documents module
         Case module
         Location module
         Application module
         Contacts module
         Grants module
The Documents module does not have any external dependencies.

Version 1.1                                                                      9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                        Resource Data, Inc
                                                         55
Resource Authorization System (RAS)
System Design


     5.5.1.4.      Presentation
The following screens provide the user interface to the Documents module.
                      Screen                                            Type

Documents                                          Detail navigation
New document                                       Detail
Add document                                       Detail
Land management documents                          Other
Add case action                                    Wizard
Search documents                                   Query

              5.5.2. Document Repository
The document repository provides the ability to store and retrieved documents. Documents
are stored in Oracle (with data type of BLOB) and searchable by keyword, case, project and
author. All document formats are supported since RAS does not address document content,
only storage and retrieval. Files are stored


                                  Templates                 Documents


                                       Repository

                           Figure 19: Document repository sub-module

     5.5.2.1.      Database
                    Table name                                      Topic area

DOCUMENT _TYPE                                     Documents
DOCUMENT_FILE_TYPE                                 Documents
DOCUMENT_PATH                                      Documents


              5.5.3. Document Templates
The Document templates sub-module provides the functionality for users to create a
document dynamically based on a standard template. The selected data is merged with a
template contain boilerplate text to create a final document.

Version 1.1                                                     9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                       Resource Data, Inc
                                              56
Resource Authorization System (RAS)
System Design


The document repository will also be used to store document templates; they will be marked
as a template and tagged with keywords and metadata to allow users the ability to know
when and where to use each template. Templates can be added, updated, or deleted the same
as any other document in the repository.




                              Documents              Repository


                                   Templates

                               Case                  Location

                              Contacts                Grants


                        Figure 20: Document templates sub-module

     5.5.3.1.   Description
RAS will support document templates into which data can be merged from system entities
(i.e. Cases, Contacts, Locations, Grants, etc.). Because the file formats of document
templates are unspecified, the specific token identifiers are left to runtime configuration.
That is, while RAS will ship with full support for a default set of document formats (in
particular, common formats based on SGML) unanticipated document formats will require
minor configuration as they are encountered. This configuration work should not require any
system downtime.
Configuration of token identifiers is to be accomplished by means of an XML configuration
file identifying mappings of token identifiers (consisting of characters or sequences of
characters) to file formats. Following is an example of such a configuration file:
          <tokens>
                <mapping fileformat=”rtf” token=”##”/>
                <mapping fileformat=”pdf” token=”%”/>
          </tokens>

   5.5.3.2.   Creating template documents
Using simple substitution
In the simplest instance, a template document may contain fields into which single values are
to be substituted for tokens. For example, assume that RAS contains a cCase with the label
―North Slope Tundra Reclamation‖ which was created on 1/1/2003, and that the name of a


Version 1.1                                                9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                  Resource Data, Inc
                                            57
Resource Authorization System (RAS)
System Design


cCase and the cCase‘s creation date are to be merged into a template containing the
following text:
          … concerning the disposition of the permit application for ##case.label, initiated on
          ##case.caseCreationDate …
Merging this case with this template will produce a document containing the following text:
          … concerning the disposition of the permit application for North Slope Tundra
          Reclamation, initiated on 1/1/2003 …
The template‘s boilerplate text is ―… concerning the disposition of the permit application for
― and ― , initiated on‖ and a system value will be substituted for ―##case.label‖ and
―##case.caseCreationDate‖ The token is the token identifier ―##‖ followed by a system
identifier using dot notation. System identifiers are to be composed of entity and field
names,derived by convention from table and column names from the data model, using dot
notation. The data model indicates that each case has a label, accessed as ―case.label‖, and a
case_creation_date, accessed as ―case.caseCreationDate‖


Iterating through multiple values
Slightly more complex is the instance in which a list of values should be substituted into a
template. Now assume that that there are three contacts for the cCase, namely Sam Smith,
John Jones, and Bob Black, and that the last names of all of the cCase‘s contacts are to be
substituted into the following text:
… the notification of all contacts, ##all(case.contacts(contact.lastName)) concerning the
disposition of the permit application for ….
Merging this case with this template will produce a document containing the following text:
          … the notification of all contacts, Smith, Jones, and Black concerning the disposition
          of the permit application for …
The data model indicates that each case may have several contacts, so the system identifier
―case.contacts‖ identifies a list of entities. Additionally, the model indicates that each
contact has a last_name. The token ―##all(case.contacts(contact.lastName))‖ will be
replaced with a comma-separated list of the last names of all the contacts for the case. The
keyword ―all‖ directs the system to iterate over the entries in the list of values returned,
accessing for each the property identified in the second pair of parentheses.


Formatting multiple values
The formatting of the resulting values defaults to a comma-and-space-separated list with a
final ―and‖ for lists of 3 or more values (i.e. ―Smith, Jones, and Black‖) and to an ―and‖-
separated list for lists with two values (i.e. ―Smith and Jones‖). This formatting can be
configured by passing additional arguments to the ―all‖ function.



Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                               58
Resource Authorization System (RAS)
System Design


In the following example, the list will be delimited by ―; ― with a final ―and ‖ for lists of 3 or
more values (i.e. ―Smith; Jones; and Black‖) and by ―and― for lists of 2 (i.e. ―Smith and
Jones‖):
          … the notification of all contacts, ##all(case.contacts(contact.lastName),‖; ―)
          concerning the disposition of the permit application for ...
Merging this cCase with this template will produce a dDocument containing the following
text:
          … the notification of all contacts, Smith; Jones; and Black concerning the disposition
          of the permit application for …
In the following example, the list will be delimited by ―; ― with a final ―or ‖ for lists of 3 or
more values (i.e. ―Smith; Jones; or Black‖) and by ―or ― for lists of 2 (i.e. ―Smith or Jones‖):
          … the notification of all contacts, ##all(case.contacts(contact.lastName),‖; ―, ―or ―)
          concerning the disposition of the permit application for ...
Merging this case with this template will produce a document containing the following text:
          … the notification of all contacts, Smith; Jones; or Black concerning the disposition
          of the permit application for …
In the following example, the list will be delimited by ―, ― (the default) with a final ―or ‖ for
lists of 3 or more values (i.e. ―Smith, Jones, or Black‖) and by ―or ― for lists of 2 (i.e. ―Smith
or Jones‖):
          … the notification of all contacts, ##all(case.contacts(contact.lastName),,―or ―)
          concerning the disposition of the permit application for ...
Merging this case with this template will produce a document containing the following text:
          … the notification of all contacts, Smith, Jones, or Black concerning the disposition
          of the permit application for …

Selecting multiple fields
In this example, the first and last names of all of the Case‘s contacts are to be substituted into
the following text:
          … the notification of all contacts, ##case.contacts((contact.firstName+‖
          ―+contact.lastName)) concerning the disposition of the permit application for ...
Merging this case with this template will produce a document containing the following text:
          … the notification of all contacts, Sam Smith, John Jones, and Bob Black concerning
          the disposition of the permit application for …

Simple substitution syntax
When the simple substitution syntax introduced earlier is used with a list value, the token will
be replaced with the first value in the list. That is, using the simple substitution syntax:

Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                               59
Resource Authorization System (RAS)
System Design


          … the notification of all contacts, ##case.contacts(contact.lastName) concerning the
          disposition of the permit application for ...
the token ―##case.contacts(contact.lastNamewill)‖ to be replaced with the last name of the
first cContact returned. Merging this case with this template will produce a document
containing the following text:
          … the notification of all contacts, Smith concerning the disposition of the permit
          application for …

Ordering multiple values
In the following example, the list will be in ascending alphabetical order (i.e. ―Black, Jones,
and Smith‖)
          … the notification of all contacts, ##all(case.contacts(contact.lastName),,,asc)
          concerning the disposition of the permit application for ...
In the following example, the list will be in descending alphabetical order (i.e. ―Smith, Jones,
and Black‖)
          … the notification of all contacts, ##all(case.contacts(contact.lastName),,,desc)
          concerning the disposition of the permit application for ...
The directives ―asc‖ and ―desc‖ are defined for numeric, string and date values. For other
types of values, these directives will be ignored. When no ordering argument is passed, the
values will be listed in no particular order.

Filtering
Lists of values can be filtered using directives. The following directives are supported.
    Operator                                            Description

equal               Supports numerics, strings, dates
                    Merging a template containing the following text:
                          … the notification of all contacts,
                          ##all(case.contacts(contact.lastName,equal(―Smith‖,‖Jones‖)))
                          concerning the disposition of the permit application for ...
                    with the case from the previous examples will produce a dDocument containing
                    the following text:
                          … the notification of all contacts, Smith and Jones concerning the
                          disposition of the permit application for …


notEqual            Supports numerics, strings, dates
                    Merging a template containing the following text:

Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                               60
Resource Authorization System (RAS)
System Design


                      … the notification of all contacts,
                      ##all(case.contacts(contact.lastName,notEqual(―Smith‖,‖Jones‖)),,,desc)
                      concerning the disposition of the permit application for ...
                 with the case from the previous examples will produce a document containing
                 the following text:
                      … the notification of all contacts, Black concerning the disposition of the
                      permit application for …


greaterThan      Supports numerics, strings, dates
                 Merging a template containing the following text:
                      … the notification of all contacts,
                      ##all(case.contacts(contact.lastName,greaterThan(―Jones‖))) concerning
                      the disposition of the permit application for ...
                 with the case from the previous examples will produce a document containing
                 the following text:
                      … the notification of all contacts, Smith concerning the disposition of the
                      permit application for …


notGreaterThan Supports numerics, strings, dates
                 Merging a template containing the following text:
                      … the notification of all contacts,
                      ##all(case.contacts(contact.lastNamenotGreaterThan,(―Jones‖)))
                      concerning the disposition of the permit application for ...
                 with the case from the previous examples will produce a document containing
                 the following text:
                      … the notification of all contacts, Black and Jones concerning the
                      disposition of the permit application for …


lessThan         Supports numerics, strings, dates
                 Merging a template containing the following text:
                      … the notification of all contacts,
                      ##all(case.contacts(contact.lastName,lessThan(―Jones‖))) concerning the
                      disposition of the permit application for ...
                 with the case from the previous examples will produce a document containing
                 the following text:
                      … the notification of all contacts, Black concerning the disposition of the
Version 1.1                                               9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                 Resource Data, Inc
                                           61
Resource Authorization System (RAS)
System Design


                     permit application for …


notLessThan     Supports numerics, strings, dates
                Merging a template containing the following text:
                     … the notification of all contacts, ##all(case.contacts(contact.lastNameL,
                     notessThan(―Jones‖))) concerning the disposition of the permit application
                     for ...
                with the case from the previous examples will produce a document containing
                the following text:
                     … the notification of all contacts, Jones and Smith concerning the
                     disposition of the permit application for …


contains        Supports strings
                Merging a template containing the following text:
                     … the notification of all contacts,
                     ##all(case.contacts(contact.lastName,contains(―s‖))) concerning the
                     disposition of the permit application for ...
                with the case from the previous examples will produce a document containing
                the following text:
                     … the notification of all contacts, Jones and Smith concerning the
                     disposition of the permit application for …


notContains     Supports strings
                Merging a template containing the following text:
                     … the notification of all contacts, ##all(case.contacts(contact.lastNameC,
                     notontains(―s‖))) concerning the disposition of the permit application for
                     ...
                with the case from the previous examples will produce a document containing
                the following text:
                     … the notification of all contacts, Black concerning the disposition of the
                     permit application for …


compound        Supports numerics, strings, dates
selection       Assume that in the previous examples, John Jones has an inactive date of
                12/31/2002, while the other two contacts have inactive dates in 2005. Merging
                a template containing the following text:
Version 1.1                                              9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                Resource Data, Inc
                                          62
Resource Authorization System (RAS)
System Design


                         … the notification of all contacts, ##all(case.contacts(contact.lastName
                         C,
                         notontains(all(case.contacts(contact.inactive_date,greaterThan(today))))))
                         concerning the disposition of the permit application for ...
                    with the case from the previous examples will produce a document containing
                    the following text:
                         … the notification of all contacts, Black and Smith concerning the
                         disposition of the permit application for …



Recursion
The data model indicates that cases themselves may have cases. Assume that the North
Slope Tundra Reclamation case has a case labeled Dalton Highway Resurfacing with a
Contact named Rob Ryan. Merging a template containing the following text:
          … the notification of all contacts,
          ##all(recurse(case.case(case.contacts(contact.lastName))) concerning the disposition
          of the permit application for …
with the case from the previous examples will produce a document containing the following
text:
       … the notification of all contacts, Black, Jones, Smith, and Ryan concerning the
       disposition of the permit application for …
Destinations for Documents resulting from template-merges
The UI will provide an opportunity to designate whether the document resulting from the
template-merge should be stored immediately into the document repository, sent to the
requesting client machine, or both.

5.6.      Rules module
By definition, a rule is a prescribed guide for conduct or action. In RAS, a rule is anything
that provides guidance, restrictions, boundaries, or requirements on activity or land in
Alaska.
The Rules module provides in RAS the capability to store and manage these many
regulations, guidelines, and policies – items like enforceable policies and attorney general
opinions. Rules can be attached to a case to set parameters for the resulting permit – as
stipulations – or to guide activity in the coastal zone – as alternative measures.
The first component of this module is a rules ―bank‖ which contains all the rules created in
RAS. The rules in the bank are created either through an administrative function or as a result
of a case being processed. For example, a Coastal Plan Review case would generate several
enforceable policies that would be stored in the rules bank.

Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                              63
Resource Authorization System (RAS)
System Design


Rules in the rule bank are classified by type (enforceable policy, general concurrence,
attorney general opinion, etc.) and can be associated with a location, as well. This provides a
mechanism to filter and organize rules, or to view rules associated with a specific area (like a
coastal zone).
Rules have also been designed with the capability to relate rules to one another or track
versions of rules. Some case types, like a Coastal Plan Review, will actually modify rules as
the case progresses. Users will review on comment on a rule, the rule will be updated, and a
new version supplied. When an adjudicator or PRC would like to use that rule in a specific
case, the rules bank will know to provide the latest version.
Rules have been designed to handle not only the typical stipulations and alternative measures
associated with a case, but also the fees, reporting requirement, bonding, and insurance
requirements included in a case. The attributes of a rule include the rule type, a dollar amount
(for fees, insurance amount, bond amount, etc.), and information about reoccurring rules.
Rules may also be configured to specify reporting requirements by the permittee (material
harvested, visitor count, etc.). The rules module supports this requirement by allowing
reported values and units to be associated with the rule specifying the reporting requirements.
Rules in the bank can be associated with a case, at which time they become a case rule. A
case rule can be thought of as an instance of a rule in the rule bank. It is based on and relates
to the rule in the rule bank, but it can be modified independent of the ―base‖ rule. When a
case is created in RAS, a set of default rules (associated with the case type template) will
automatically become case rules for that case. Additionally, rules in the rule bank that are in
the same location as the case may be added to the case.
Rules are created in RAS either as an administrative function (input directly into the rules
bank by a system administrator) or as a result of a case being processed (Coastal Plan review,
for example). In the case of rules being added as a result of a case being processed, the
driving requirement is a Coastal Plan Review case type. These cases will propose rules, other
users will comment on the rule, and then a new version of the rule will be issued. The final
versions of these rules will become enforceable policies for the coastal zone they apply to. As
other cases (LUP, CR) are processed, they will use apply these enforceable policies as case
rules. RAS will automatically take the latest version of a rule when used as a case rule.
However, the rule revision history will be tracked.




Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                              64
Resource Authorization System (RAS)
System Design




                                        Rules
                        Documents                       Contacts

                            Case                        Location


                                  Figure 21: Rules module

     5.6.1.1.   Database
The following tables are part of the Rules module:
                 Table name                                     Topic area

RULE                                            Rules
RELATED_RULE                                    Rules
RULE_LOCATION                                   Rules
RELATED_RULE_TYPE                               Rules
RULE_TYPE                                       Rules
RULE_COMMENT                                    Rules
CASE_RULE                                       Rules
REPORTED                                        Rules
REPORTED_MEASURE_UNIT                           Rules

     5.6.1.2.   Business logic
The Rules module supports the following use cases.
                Use cases                                        Use cases

2.25 Add stipulations and fees                    13.6 Review and Comment on Policy
                                                  (Agency)
2.26 Add bond amount and                          13.12 Review Policies
information
2.27 Add insurance information                    13.13 Submit Comment for a Policy

Version 1.1                                                 9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                   Resource Data, Inc
                                           65
Resource Authorization System (RAS)
System Design


13.2 Create Policy                                                             13.14 Review Approved Policies
13.3 Edit Policy                                                               13.18 Assign Policies to Bank
13.4 Delete Policy
Rules will have a current version, a version history, and a set of related rules.
                   RuleHistory
                                                                                                              RelatedRules
        + prevRule : Rule
        + nextRule : Rule                                                                         + rule      : Rule
                                                                                            1
        + comments : java.lang.String                                                             + relatedBy : java.lang.String
                                                     1
        + getCurrentVersion () : Rule
        + addNewVersion ()     : void



                                                             1                          1
                                                                      Rule
                                                 +       ruleId            :   int                                             ICollection
                                                 +       name              :   java.lang.String
                                                 +       description       :   java.lang.String
                                                 +       expireDate        :   java.util.Date                        +   add ()        :   void
                                                 +       amount            :   int                                   +   clear ()      :   void
                                                 +       amountInterval    :   int                                   +   contains ()   :   boolean
                  ILinkedList
                                                 +       renewDate         :   java.util.Date                        +   equals ()     :   boolean
                                                 +       parentRuleNotes   :   java.lang.String                      +   remove ()     :   void
   +   size ()        : int                      +       parentRule        :   Rule                                  +   size ()       :   int
   +   getFirst ()    : java.lang.String         +       ruleType          :   java.lang.String
   +   getLast ()     : java.lang.String
   +   setFirst ()    : void
   +   setLast ()     : void
   +   removeFirst () : void
   +   removeLast () : void
   +   add ()         : void
   +   clear ()       : void
   +   contains ()    : boolean
   +   get ()         : Object
   +   set ()         : void                                                                                                 CaseRules
                                                                    CaseRule
   +   remove ()      : void                                                                           0..*               + case : Case
                                                     +    rule             :   Rule
                                                     +    notes            :   java.lang.String                  1
                                                     +    reportRequired   :   boolean
                                                     +    reportInterval   :   int

                                            1




                                         0..*

                          Reported
          +   reportedId         :   int
          +   dateReported       :   java.util.Date
          +   periodReported     :   java.lang.String
          +   quantity           :   int
          +   unit               :   java.lang.String



                                           Figure 22: Rules module object model

Version 1.1                                                                                     9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                       Resource Data, Inc
                                                                     66
Resource Authorization System (RAS)
System Design


     5.6.1.3.   Integration
Modules and systems that rely on the Rules module
         Case module
Modules and systems that the Rules module relies on
         Location module
         Contacts module

     5.6.1.4.   Presentation
Many of the screens identified in the Screen Prototypes document (Deliverable 2.3) are
designed specifically to accommodate Coastal Plan management. Since the publication of
that document, we have actually broadened this module to encompass those screens in to a
more generic interface for all rules and rule types. An enforceable policy rule is now simply
one type of rule supported by the Rules module.
                      Screen                                         Type

Stipulations                                     Detail
Add stipulations                                 Detail
Stipulation details                              Detail
Rule comments                                    Detail
Comment on rule                                  Detail
Respond to rule comment                          Detail
Rules                                            Detail
Revise rule                                      Detail

5.7.      Grants module



                                        Grants
                                 Case                     Contacts

                               Documents                  Location



Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                            67
Resource Authorization System (RAS)
System Design


                                   Figure 23: Grants module
The Grants module is designed primarily to support the tracking and reporting of Grant
information. Since the Grants administered by OPMP are provided by the National
Oceanographic and Atmospheric Administration (NOAA) and typically fund activities in the
coastal zone, many of the contacts, locations and projects are the same as those used in the
Case Management module.
It is anticipated that the overlap point between grants and case management will be through
the project subject area. Projects are defined as the activity in which the customer is
engaged; this is independent of authorizations or grants (e.g. a project can exist without any
authorization or grant).

    5.7.1.1.    Database
The database component of the grants module primarily consists of the tables in the Grants
topic area of the physical data model. The list of specific tables used in this module is listed
below.

                Table name                                        Topic area

GRANT                                              Grants
BLOCK_GRANT                                        Grants
GRANT_SUBJECT                                      Grants
GRANT_STATUS                                       Grants
GRANT_FUNDS                                        Grants
GRANT_FUNDS_TYPE                                   Grants
GRANT_TASK                                         Grants
GRANT_CONTACT                                      Grants
GRANT_CONTACT_TYPE                                 Grants
GRANT_AMENDMENT                                    Grants
GRANT_BLOCK_GRANT_XREF                             Grants
GRANT_TASK_DOC_XREF                                Grants
GRANT_DOCUMENT_XREF                                Grants
GRANT_PROJECT_XREF                                 Grants


     5.7.1.2.   Business logic
The following use cases are covered in the Grants module:


Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                              68
Resource Authorization System (RAS)
System Design


              Use cases                                          Use cases

8.1 Submit grant report                           8.5 Record carry forward funds
8.2 Compile federal performance                   8.6 Close grant
report
8.3 Submit monthly news bullet                    8.7 Run grant reports
8.4 Record grant awards
A block grant will be dispersed in the form of several different grants. Each of these grants
will have funding of various types and amounts. Additionally, grants can be amended and
amounts changed based on the amendment.




Version 1.1                                                 9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                   Resource Data, Inc
                                             69
Resource Authorization System (RAS)
System Design

                                                                                                         Grant
                                                                     -   grantId           : int
                                                                     -   summary           : java.lang.String
                                                                     -   grantNumber       : java.lang.String
                                                                     -   approvalDate      : java.util.Date
                  BlockGrant                                         -   startDate         : java.util.Date
   +   blockGrantId     : int                                        -   endDate           : java.util.Date
   +   year             : java.util.Date                             -   enNumber          : java.lang.String
   +   amount           : double                                     -   status            : java.lang.String
   +   name             : java.lang.String                           -   grantSubject      : java.lang.String
                                                  1       0..*
   +   description      : java.lang.String                           +   organization      : Organization
   +   subject          : java.lang.String                           +   rsaNumber         : int
   +   grantNumber      : int                                        +   project           : Project
   +   startDate        : java.util.Date                             +   grantFundings     : Collection
   +   endDate          : java.util.Date                             +   grantDocuments    : Collection
   +   trackingNumber   : int                                        +   prevGrant         : Grant
   +   grants           : Collection                                 +   nextGrant         : Grant
   + addGrant () : void                                              +   addGrantFunding ()                       : boolean
                                                                     +   getGrantAmendments ()                    : Collection
                                                                     +   updateGrantStatus ()                     : void
                                                                     +   ammendGrant ()                           : GrantAmmendment
                                                                     +   grantTotalByType (java.lang.String type) : double
                                                                     +   grantTotal ()                            : double
                                                                     +   addGrantDoc ()                           : void
                                                                     +   removeGrantDoc ()                        : void
                                                                     +   closeGrant ()                            : void
                                                                          GrantContacts
                                                                          GrantTasks


                                                                                                  1




                                                                                                  0..*


                                                                                       GrantFunding
                                                                 +   grantFundingId       : int
                                                                 +   amount               : double
                               GrantTasks                        +   fundingDate          : java.util.Date                               GrantContacts
                    + grantTasks : Collection                    +   notes                : java.lang.String
                    +   sort ()     : void                       +   type                 : java.lang.String
                                                                 +   ammendment           : GrantAmmendment                          +   sort ()      : void
                    +   find ()     : void
                                                                 +   prevGrantFunding     : GrantFunding                             +   find ()      : void
                    +   add ()      : void
                                                                 +   nextGrantFunding     : GrantFunding                             +   add ()       : void
                    +   remove ()   : void
                                                                 + grantTotalByType (java.lang.String type) : double                 +   remove ()    : void
                                                                 + reprogramGrant ()                        : void
                                    1                            + carryForwardFunds ()                     : void                                1

                                    0..*                                                      1
                                                                                             0..1
                                                                                                                                                  0..*
                            GrantTask                                             GrantAmmendment
                                                                                                                                          GrantContact
           +   grantTaskId          : int                            +   grantAmmendmentId        : int
           +   grant                : Grant                          +   ammendedAmount           : double                   -   grantContactId   : int
           +   label                : java.lang.String               +   notes                    : java.lang.String         -   contact          : Contact
           +   description          : java.lang.String               +   approvalDate             : java.util.Date           +   contactType      : java.lang.String
           +   parentGrantTaskId    : java.lang.Integer              +   startDate                : java.util.Date           +   prevContact      : GrantContact
           +   taskDocList          : Collection                     +   endDate                  : java.util.Date           +   nextContact      : GrantContact




                                               Figure 24: Grants module object model

       5.7.1.3.          Integration
There are not any modules or systems that rely on the Grants module. The modules and
systems that the Grants module relies on are:
           Documents module

Version 1.1                                                                                                      9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                                        Resource Data, Inc
                                                                                  70
Resource Authorization System (RAS)
System Design


         Case module (Projects sub-module)
         Contacts module
         Location module

     5.7.1.4.    Presentation
The following screens are included in the Grants module:
                    Screen                                             Type

New grant                                          Detail
Grant details                                      Detail
Grant reports                                      Other
Grant funding                                      Detail
Submit grant report                                Detail
Submit news bullet                                 Detail
Search grants                                      Query
Grant user home page                               Detail navigation
Grant tasks                                        Query

     5.7.1.5.    Reports
The following reports are included in this module:
         Coastal Management Grant Program Information
         Quarterly Fiscal Summary Report
         OPMP Section 306B Project Consistency Review Statistics
         Single Agency Review, Monitoring and Compliance for Section 306B Report
         Agency Review, Monitoring and Compliance Summary Report
         Grant Reports Status
         Participation in OPMP Consistency Reviews


5.8.      Security module
In an application the size or RAS, security is really an infrastructure component; it spans the
entire suite of modules within the system. The security module here is no different, and our
design spans not only the entire set of modules, but also encompasses a few tiers of the
system.


Version 1.1                                                    9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                      Resource Data, Inc
                                              71
Resource Authorization System (RAS)
System Design


Database security is required to support the different types of data access required by
different roles. For example, a case report for an adjudicator will show all case notes. The
same report for a member of the public would not show case notes.
The security model also applies to the presentation tier. Some screens may be read only for
one type of user, but updateable for another type of user. The security model also
encompasses a certain level of personalization based on role; one user may see a different
prompt than another user based on their user role.
The security model is designed to operate by permission. If an object does not exist in the
object table, there is no security applied to the object and everyone will have access to it.
However, if the object is listed in the table, than only those roles listed will have access to the
object. The security module contains a set of screens to allow administrators the ability to
add, update, and delete security permissions for users and roles.
The security model must also support the requirement for the changing security requirements
of a case as it is processed. This temporal security is supported by applying security profiles
(a matrix of which roles have access to which objects) at runtime based on the last milestone
achieved.
The general user community for RAS consists of the general public, public users, State of
Alaska employees not associated with the DNR, and DNR users. The descriptions of these
groupings are below.
         General public will use this application to view public notices, view information
          about state land, and understand the services DNR provides. The general public will
          not need to login to the system.
         Public user is a member of the general public who will use RAS to submit
          applications online, review and comment on public notices, track their application as
          it is processed by DNR, and conduct general communication with DNR after
          completing the application process. A public user must login to the system.
         Other agency users will use RAS to work with DNR to conduct agency reviews and
          obtain information from DNR.
         DNR users are the primary user group for the system and include adjudicators and
          project review coordinators. Other DNR staff will use this system in a variety of
          ways, as well, and is detailed in the security section.




Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                              72
Resource Authorization System (RAS)
System Design




                                     Security
                                        Contacts

                                 Figure 25: Security module

     5.8.1.1.   Database
                  Table name                                    Topic area

USERS                                           Users and Roles
USER_ROLES_XREF                                 Users and Roles
ROLES                                           Users and Roles
TEMPLATE_ROLES_XREF                             Users and Roles
SECURE_OBJECT                                   Security
SECURE_OBJECT_ROLES                             Security
SECURE_OBJECT_TYPE                              Security
SECURITY_LEVEL_TYPE                             Security
PROFILES                                        Security
TMPL_CASE_MILETONE_PROFILE_XREF Security

     5.8.1.2.   Business Logic
The Security module covers the following use cases:
                Use cases                                       Use cases

6.1 New user registration                       9.2 Maintain DNR users
6.2 Log in to system                            9.3 Maintain public users
9.1 Maintain user roles




Version 1.1                                                9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                  Resource Data, Inc
                                           73
Resource Authorization System (RAS)
System Design


                                  User
                                                                                                Role
                +   username      :   java.lang.String
                +   password      :   java.lang.String                0..*   +   roleId          :   int
                +   userId        :   int                                    +   name            :   java.lang.String
                +   contact       :   Contact                                +   description     :   java.lang.String
                +   roleList      :   Collection         1                   +   organization    :   Organization
                +   profileList   :   Collection
                + login () : void

                                         0..1


                          0..*
                                                                                      SecureObjectRole
                                  Profile                                    +   name            :   java.lang.String
              + name             : java.lang.String                          +   type            :   java.lang.String
                                                             0..1    0..*
              + description      : java.lang.String                          +   prompt          :   java.lang.String
              + secureObjectList : Collection                                +   role            :   Role
                                                                             +   secureObject    :   SecureObject



                                        Figure 26: Security module object model

     5.8.1.3.       Integration
All aspects of RAS rely on the Security module to provide authentication, verify access, or
present the appropriate user interface.
The Security module relies on the Contacts module to maintain the contact information about
the user as well as the relationship of the user to an organization.

     5.8.1.4.       Presentation
                         Screen                                                           Type

Login                                                             Detail
DNR user home page                                                Home page
Agency user home page                                             Home page
Applicant home page                                               Home page
New user registration                                             Detail
Search users                                                      Query
User details                                                      Detail
Roles                                                             Detail

5.9.      Application module
The application module provides the infrastructure for users to complete an online
application and store the entered data. Once an application is submitted, RAS will relate the
submitted application to the case for future reference.

Version 1.1                                                                       9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                         Resource Data, Inc
                                                             74
Resource Authorization System (RAS)
System Design


One feature that has been requested of the application module is the ability to base a new
application on an existing application. For example, a user that completes and submits a
CPQ, and then later finds out they need to apply for a LUP as well should not need to fill out
the information that is common to each application. Instead, a feature will allow them to base
the LUP application off of the CPQ information. A routine will be provided to populate and
common information in the LUP from the CPQ.
It is anticipated that the Unified Permitting project will replace this module with a more
robust and complete online application system.




                                   Application

                            Documents                    Location

                                         Contacts

     5.9.1.1.   Database
                 Table name                                          Topic area

CASE_APPLICATION                                  Applications
APPLICATION_CONTACT_XREF                          Applications
APPLICATION_LOCATION_XREF                         Applications
APPLICATION_DOCUMENT_XREF                         Applications
LAND_USE                                          Applications
COMMERCIAL_RECREATION                             Applications
CONSISTENCY_REVIEW                                Applications
CON_REVIEW_OTHER_PERMIT                           Applications
CON_REVIEW_APPROVAL                               Applications

     5.9.1.2.   Business Logic
The following use cases are fulfilled through the Applications module:
                Use cases                                             Use cases

1.1 Start application                               1.10 Save application

Version 1.1                                                      9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                        Resource Data, Inc
                                             75
Resource Authorization System (RAS)
System Design


1.2 Resume application                                         1.11 Discard application
1.4 Complete Land Use Permit (LUP)                             1.12 Check application status
application
1.5 Complete Commercial Recreation                             1.14 Select application type
Permit (CRP) application
1.6 Complete Coastal Project                                   1.15 Add authorized user to
Questionnaire (CPQ) application                                application
1.7 Complete contact information                               2.2 Enter Land Use Permit (LUP)
                                                               information
1.8 Agree to terms                                             2.3 Enter Commercial Recreation
                                                               Permit (CRP) information
1.9 Submit application                                         2.4 Enter Consistency Review (CR)
                                                               information
An application object will represent the basic functionality needed for each application type,
as well as the relationships to other entities. The data for each application will reside in a
structure identical to what is depicted in the physical data model.
                                                Application
                                   +   status             :   java.lang.String
                                   +   appDocuments       :   Collection
                                   +   appLocations       :   Collection
                                   +   appContacts        :   Collection
                                   + updateStatus () : void


                                                          1




                                              0..*
                                             ApplicationContact
                                       + contact  : Contact
                                       + type     : java.lang.String
                                       + shareApp : boolean



                            Figure 27: Application module object model

     5.9.1.3.   Integration
Modules and systems that rely on the Application module
         Case module
Modules and systems that the Application module relies on
         Location module


Version 1.1                                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                    Resource Data, Inc
                                                     76
Resource Authorization System (RAS)
System Design


         Contacts module
         Documents module

     5.9.1.4.    Presentation
                    Screen                                            Type

Application overview                             Detail navigation
Add authorized user                              Detail
Amend application                                Detail
Start application                                Permit application
Choose application type                          Wizard
LUP application                                  Permit application
CRP application
CPQ
Contact information                              Detail
Submit application                               Detail
Agree to terms                                   Detail


     5.9.1.5.    Reports
Reports included in this module are:
         Coastal Project Questionnaire
         Commercial Recreation Permit Application / Permit
         Land Use Permit Application
         Land Use Permit

5.10. Administration module
The Administration module covers the entire RAS application. Through this module, a
system administrator will be able to maintain lookup list values, maintain the user and role
lists, and modify and create case type templates.




                                 Administration

Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                            77
Resource Authorization System (RAS)
System Design


                               Figure 28: Administration module

     5.10.1.1.   Database
In addition to the following tables, Oracle system metadata will be used for managing the
lookup list tables.
                  Table name                                     Topic area

TEMPLATES                                        Templates
T_CASE_RULES                                     Templates
T_CASE_CONTACT_TYPE                              Templates
T_CLOCKS                                         Templates
T_ACTIVITY_TYPE                                  Templates
T_CASE_ACTION_TYPE                               Templates
T_PHASE_ACTION                                   Templates
T_PHASE                                          Templates
T_CASE_MILESTONES                                Templates
T_RELATED_MILESTONES                             Templates


     5.10.1.2.   Business Logic
The Administration module covers the following use cases:
                 Use cases                                        Use cases

9.4 Add a new case type                            9.8 Add document template to library
9.5 Modify case template                           9.9 Add a report
9.6 Expire a case template                         9.10 Modify a report
9.7 Maintain lookup lists                          9.11 Remove a report




Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                            78
Resource Authorization System (RAS)
System Design


                            Admin
                   + users     : Collection
                   + reports   : Collection
                   + templates : Collection



                                  1      1
                                                                             Report
                                                              + reportName : java.lang.String
                                                      0..*
                                                              + location   : java.lang.String
                                                              + roles      : Collection




                                                              Template
                                                 +   templateId     : int
                                                 +   caseType       : java.lang.String
                                                 +   version        : double
                                                 +   createDate     : java.util.Date
                                          0..*   +   isCurrent      : boolean
                                                 +   description    : java.lang.String
                                                 +   milestones     : MilestoneGraph
                                                 +   actionTypes    : Collection
                                                 +   rules          : Collection
                                                 +   activities     : Collection
                                                 +   contactTypes   : Collection



                          Figure 29: Administration module object model

     5.10.1.3.   Presentation
The following screens are included in this module:
                    Screen                                                         Type

Search users                                              Query
User details                                              Detail
Roles                                                     Detail
Modify case type template                                 Detail
Case type templates                                       Detail
New case type template                                    Wizard
Lookup lists                                              Other
Maintain reports                                          Query
Maintain document templates                               Query




Version 1.1                                                                9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                  Resource Data, Inc
                                                     79
Resource Authorization System (RAS)
System Design


5.11. Reporting Engine
Many of the RAS modules include reports. The reporting engine described here will be
responsible for running the reports.
Each report will be created essentially as a Java Server Page and defined as part of the web
application. The run reports screen will be presented to the user, with a personalized list of
available reports based on their security permissions. Each listed report will also have a set of
parameters the user can set values for. These will be passed to the report at run time. The
report will be generated using the RAS J2EE architecture, and then presented to the user as a
web page displayed in a separate window. If new reports that require a servlet or separate
class are added to the system, the web application will need to be restarted.
The resulting report window will be slightly customized in that it will not include any
navigational components. Users will be able to print the report using the browser‘s print
feature. If an Adobe PDF output is needed, the user must have the appropriate software
installed on their system and output the web page to Adobe PDF.
Certain generated reports can be configured to automatically be added to the document
repository based on the parameters supplied. For example, the Case Summary Report for a
given case number could automatically be added (as an HTML document) to the document
repository tagged with the corresponding case number.

     5.11.1. Presentation
The following screens are included in this module. The report screens are a placeholder as
the list of reports is included in the reports deliverable (Deliverable 1.10a Report
Specifications v1.3.doc) located at www.resdat.com/deliverables.


                  Screen                                             Type

Run Report                                        Detail
Report screens                                    Other




Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                             80
Resource Authorization System (RAS)
System Design



6. Case Type Sample: LUP
The Land Use permitting process represents one of the fundamental features of the Resource
Authorization System. In the following section, we provide details for how the Land Use
permit process is facilitated with the RAS template structure.
Land Use Permits, like all the permitting and review processes supported by RAS, begin with
the same basic structure. This structure includes items such as phases, temporal events
(milestones), valid case actions, case sub-types, etc. When a user creates a new case, and
indicates its case type as ―Land Use‖, the template system automatically loads the structure
to facilitate the lifecycle of a typical Land Use Permit.
While all Land Use Permits begin with the same basic structure, many are altered as their
individual lifecycles progress. To facilitate these in-process modifications, the structure of
items such as milestones, actions, clocks, etc. may be altered during any part of the LUP
permitting process.
The first step in establishing Land Use Permits as a valid case type is the creation of a case
type template within the administrative section of the RAS application structure. The case
type template defines the beginning parameters for any case type within the system. In the
case of Land Use Permits, the user would configure the following template parameters:
         Phases
         Actions
         Milestones
         Rules
         Activity Types
Beyond the template structure, other topic areas of the application are utilized during the
processing of a Land Use Permit application. These areas, like Contacts and Documents are
used in much the same fashion for most case types (Land Use Permit, Consistency Review,
etc.). For a Land Use Permit, users would have the option of relating data to the case in the
following areas:
         Documents
         Contacts
         Applications
         Locations
         Distribution Lists
Use of these areas for all case types has been covered in significant detail throughout the
design document and accompanying technical specifications. Therefore, the focus of the
Land Use Permit case type example will largely be on the template-based elements.




Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                             81
Resource Authorization System (RAS)
System Design



6.1.      Template Elements
     6.1.1. Phases
The phases of a typical Land Use Permit lifecycle are clearly defined through the business
process currently in place. The phases include (in order of their occurrence as time
progresses):
     1.   Pre-Application
     2.   Application
     3.   Adjudication
     4.   Issuance
     5.   Monitoring and Compliance
     6.   Closure
These items would be created through the administrative interface and would ultimately be
stored in the T_PHASE entity. While this is their storage location, their implementation
would begin in the PHASE entity. Through the relationship between phases and milestones,
a single phase is related to at least two related milestones. If only two are related, they
indicate the beginning and ending of a phase. If other milestones exist and occur during a
specific phase they are related to the phase through the constraint that exists between the
PHASE and RELATED_MILESTONES entity. The administrative interface designed to
facilitate case type setup will allow the creation of as many milestones (and their links to
phases) as are necessary.

     6.1.2. Milestones
Within the scope of RAS, a Milestone is an event in time that marks the beginning and/or
ending of distinct periods of time. Milestones are only achieved by the execution of an
action (user or system initiated).
                                           Milestones




                                              Time



Milestones represent the points on the RAS timeline. Many are automatically defined and
loaded into the database at the time a user creates a new case. For example, a point in time
always exists for the receipt of the application and fees in the case of a Land Use Permit. As
does another point in time for the approval and activation of the permit itself. These points in
time, or milestones, are only two of many that are known to exist during the lifecycle of
every Land Use Permit.
The following list contains Milestones that are known to exist for the Land Use permitting
process. They would be inserted using the administrative case type creation tool (interface)
and stored in the template section of the system database. During normal user interface
operation, the Milestones would be automatically loaded in the CASE_MILESTONE and

Version 1.1                                                 9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                   Resource Data, Inc
                                             82
Resource Authorization System (RAS)
System Design


RELATED_CASE_MILESTONE entities when a user selects the Land Use Permit case
type.
      1. Pre-Application Initiated
      2. Application Received
      3. All Fees Received
      4. Application Approved/Adjudication Initiated
      5. Agency Review Initiated
      6. Agency Review Concluded
      7. Draft Conclusion Submitted
      8. Public Comment Period Initiated
      9. Public Comment Period Concluded
      10. Final Conclusion Submitted
      11. Permit Issued
      12. Reporting Required
      13. Fees (Renewal) Required
      14. Permit Closed
The diagram below illustrates the Milestones listed above along a typical Land Use Permit
lifecycle timeline along with corresponding Phases.
          Pre App       Application                   Adjudication                   Monitoring/Compliance

                                                            Time

  1                 2                 3   4   5   6   7           8   9 10 11                  12 13         14




      6.1.3. Actions
Actions in the RAS application represent the individual physical actions taken by users
during the lifecycle of any case. Actions can be anything from a simple phone call to the
scheduled process for initiating the public comment period. The individual actions taken
during a case lifecycle may be gathered into a collection to produce the Action Log, a
complete listing of all actions taken.
In order to maintain database structure and data integrity, the available actions are limited to
a pre-defined list (look-up). Each Action available to a user during the Land Use permitting
process is made available during the creation of the case type template. During this phase,
the user defines the valid Actions for the new case type. For Land Use Permits, the
following actions are valid:
            Informal Pre-Application Meeting (Phone/In-Person)
            Received Application
            Received Application Fee
            Received Bond
            Received Insurance
            Marked Application as Complete and Ready for Adjudication
            Routed Case to Agency for Review

Version 1.1                                                              9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                Resource Data, Inc
                                                             83
Resource Authorization System (RAS)
System Design


         Received Case Comment from Agency after Review
         Requested Additional Information from Applicant
         Received Additional Information from Applicant
         Requested Additional Information from Agency
         Received Additional Information from Agency
         Sent Public Notice Announcement
         Received Public Comment (Phone/Hard Copy/In-Person/Electronic)
         Submitted Draft Conclusion
         Submitted Final Conclusion
         Issued Permit/Permit Activated
         Received Signed Permit as Issued
         Site Visited (Monitoring/Compliance)
         Applicant Contacted for Permit Violation
         Trespass Notification Sent
         Received Decision Appeal
         Sent Reporting Correspondence to Permit Holder
         Annual Report Received
         Permit Expired/Case Closed
It is expected that many of the valid Actions for a particular case type will be system
triggered, while others will be manually entered as ―Actions‖. For example, a user that
engages in simple telephone correspondence with a potential applicant would need to enter
the details of the phone conversation in the ―action‖ section of the RAS application. The
same user would use an entirely different section of the interface to issue the permit later in
the lifecycle of the case. However, when engaging the system to issue the permit, the system
would automatically be submitting a new entry in the action log. The action is entered by the
system in response to the user issuing the permit.
Some actions will require additional information or functionality when they are selected.
These actions are the reverse of those described in the previous paragraph, rather than a
system function automatically entering an action, an action automatically triggers supplement
system function(s). A prime example of this process may be illustrated by the series of
events related to the initiation of the public comment period. When a user initiates the public
comment period, they enter it as an action. After selecting the action from the list of valid
actions, the system will prompt them to enter additional information such as selecting the
public notice template, distribution list, method of communication, etc. The completion of
this process in response to selecting the ―Sent Public Notice Announcement‖ action will
ensure the process is completed fully and the data has been properly saved in the database.

     6.1.4. Rules
Rules represent the topic area of the application set aside for stipulations, enforceable
policies, alternative measures and other constraints placed on permits and conclusions. In
most cases, the rules relate to what is expected of the individual or group that is granted the
permit. In simple terms, they help define what the permitted individual or group is expected
to do or not do.
Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                             84
Resource Authorization System (RAS)
System Design


All Rules are created using the administrative interface. During the process of creating a new
case type, Rules may be created and assigned as default or they may be created as the case
progresses through the Land Use Permit lifecycle. The default Rules are automatically
assigned when a new case is created using the case type that references them. Non-default
Rules are created and/or assigned during the application and/or adjudication process. For
example, a case may be created to respond to a Land Use Permit application, but it is not
determined until late in the adjudication phase how much of a fee will be required if the
permit is for a tourism/guiding operation. The fee itself is attached to the permit as a Rule
and has additional reporting Rules that accompany it.
For the Land Use Permit case type, the Rules section is largely focused on site use
regulations, fee and reporting requirements that accompany the issued permit. Individual
default Rules will be created during the template definition phase. These rules will be
attached to specific activity types, such as guiding, mining and non-timber forest product
harvesting. When a case is created using the Land Use Permit as a case type and one of the
referenced activity types, the system will automatically reference rules associated with
required fees and reporting (such as the pounds of non-timber forest product and how often it
is to be reported). Two or more fee rules could apply and would trigger a choice by the
adjudicator.
The assignment of some Rules to a case will result in the creation of new Milestones.
However, this is not true for all cases and is usually specific to those with reporting
requirements. For those permits requiring specific fees and reporting, new Milestones will
be created (along with system triggers, or notification ―ticklers‖) that indicate when
reports/fees are due.
During the adjudication process, adjudicators may find it necessary to add rules or modify a
rule already (automatically) assigned to a potential permit. Using the standard adjudication
case management interface, users with adjudicator rights will be able to make all necessary
adjustments (add, edit, delete) to the rules which will ultimately be part of the issued permit.
The following Rules are expected to exist for Land Use Permits:
         Bonding Requirements
         Insurance Requirements
         Head Fees (guiding/tourism)
         Annual Fees
         Harvest Fees (natural resource extraction/removal)
         Annual Reporting Requirements
         Close-out/Completion Reporting Requirements
         Posting Requirements
         Standard Rules/Guidelines
              o Public Access
              o Public Trust Doctrine
              o Site Disturbance
              o Timber Use
              o Fire Prevention, Protection and Liability

Version 1.1                                                    9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                      Resource Data, Inc
                                              85
Resource Authorization System (RAS)
System Design


              o Hazardous Substances
              o Spill Notification
              o Operation of Vehicles
              o Alaska Historic Preservation Act
              o Inspections
              o Assignment
              o Indemnification
              o Violations
         Structures
         Waste and Wastewater Disposal
         Food Storage
         Fuel and Hazardous Substance Storage
         Restoration of Site
         Short Term Camp Regulations
Areas of the RAS architecture such as Documents and Locations have a relationship with
some rules. Rules that only apply to specific geographic locations will be automatically
assigned to cases occurring within the geographic boundary of the rule. Likewise, rules that
include specific reporting requirements may have document templates or system reports
stored in the Documents section of the application that may be produced automatically when
the reporting period draws near. For Land Use Permits, the following relationships exist
between Rules and other sections of the architecture:
     Documents
      Reporting Reminders
          o Notification that a periodic report is due in the near future.
          o Notification that a periodic report is overdue.
      Reporting Templates
          o Standard documents to be submitted (completed) periodically and returned to
              the originating agency.
     Locations
      No fuel within 50‘ of a water body.
      Travel restrictions based on location and/or time of year.
      Special use restrictions if the project takes place within the coastal zone.
      Special consideration if the project takes place within some organized community
        boundaries.
      Environmentally sensitive areas.
While many RAS rules will be pre-defined during the template creation administrative task,
the system will allow the creation and maintenance of new rules over time on an as-needed
basis.

     6.1.5. Activity Types
Within the Resource Authorization System, an Activity Type is defined as what the applicant
is intending to do on state land, the actual physical activity. Some examples include

Version 1.1                                               9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                 Resource Data, Inc
                                            86
Resource Authorization System (RAS)
System Design


harvesting lichens, providing tourist guide services and setting up logging facilities. RAS is
being designed to store a vast listing of activities for applicants and adjudicators to choose
from. This listing will include activities not only designed for Land Use Permits, but for
Consistency Reviews and Commercial Recreational Permits as well.
In the case of Land Use Permits, the master activity list (see the ACTIVITY_TYPE entity)
will be filtered to provide a more concise listing of activities that pertain only to the case type
created for Land Use Permits. The process of selecting and maintaining the valid activity list
will take place within the administrative interface.
Ultimately, the list of activities will closely follow the same subjects established in LAS.
However, until the final list is created, we can provide a basic structure of activity areas that
will be available. Some examples of activities that may be made available to applicants and
adjudicators include:
         Mining
              o Mineral
              o Coal
              o Precious Metal
         Timber Harvesting
              o Log Transfer Facility
              o Log Storage Facility
         Non-Timber Forest Product Harvesting
              o Lichens
              o Mushrooms
              o Other
         Petroleum Development
              o Oil
              o Gas
                      Surface
                      Sub-Surface
         Tourism/Guiding
              o Floating Lodge
              o Seasonal Camp
              o Temporary Camp
         Tideland Structure
              o Lodge
              o Dock
                      Construction
                      Enhancement




Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                              87
Resource Authorization System (RAS)
System Design



7. Tying it all together – the case timeline in depth
7.1.      Introduction
The RAS timeline functions include Milestones, Actions, Clocks and Phases. Three of these
components (Milestones, Clocks and Phases) form a virtual scheduling sub-system within the
RAS design concept. When defined for a case, they give the case temporal definition
through discrete events in time (Milestones), case processing duration tracking (Clocks) and
real-time access to current case file phase. The final component, Actions, ties all of these
elements together. Through the standard RAS user interface, adjudicators (and other users)
will have the ability to save data related to the actions they have taken on a case during its
lifecycle. As detailed in this document, actions may record an event (having no direct effect
on the system) or they may achieve a milestone.
The purpose of this document is to outline the business definition and proposed design of
each of the 4 major elements of the Timeline sub-system: Milestones, Actions, Phases and
Clocks.

7.2.      Milestones
Within the RAS architecture, Milestones may be defined simply as individual events in time
that may only be achieved through the execution of an action (see Actions). Milestones form a
chain of events along the lifecycle timeline of the land use permitting process or consistency
review process. Milestones may be either predefined for a specific case type or created by
the system in response to the execution of actions.

     7.2.1. Business Definition
The need to track and catalog the details surrounding discrete events in time is found
throughout the review processes in place at the Division of Mining, Land and Water and the
Office of Project Management and Permitting. The RAS concept of Milestone was built
around this need.
While the RAS design proposes the implementation of functionality capable of tracking all
the actions taken during a case lifecycle, only certain events are defined as milestones. The
subjective nature of milestone definition is a major component of the flexibility of case
timeline configuration. What is considered a milestone-worthy event and what is not can be
quite different depending on the review process being established. For this reason,
milestones and actions are configured through an administrative interface leaving the details
up to the administrative user.

     7.2.2. System Definition
From the perspective of RAS, Milestones are defined primarily at the database and
application level. Users have the ability to create milestones and view or manipulate various
attributes of Milestones through the interface, but the logic behind these elements exists
within the lower two tiers (application and database) or the system.

Version 1.1                                                 9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                   Resource Data, Inc
                                            88
Resource Authorization System (RAS)
System Design



At the database level, Milestones are defined within RAS as records with integral
relationships to Cases, Clocks, Phases, Actions and other Milestones. At the application
level, Milestones exist as members of logical classes each with distinct attributes.

     7.2.3. Milestone Classes
There are four Milestone classes:

     7.2.3.1.   Fixed Date (Series)
This milestone occurs on an exact calendar date and time. The date/time is an attribute of the
milestone record.
The first milestone in a series of related milestones is fixed. An action triggers the
achievement of the milestone and populates the date/time for that milestone.
Typically, the actual date of occurrence of the first milestone in a series, the Initialization
Milestone (IM), is set by the action taken to signify the achievement of the IM. For example,
at the beginning of both the Land Use Permit process and the Consistency Review process,
the business process itself is initiated as a result of receipt of the applicant‘s paperwork
(among other criteria). In the system, an action is created (entered) to signify the receipt of
this information and the beginning of the project. The action entered is ―linked‖ to a
milestone, the first milestone of a series. Because it is linked to an action that has been
taken, the milestone has an achievement date/time.

     7.2.3.2.   Fixed Date (Independent)
Fixed Milestones that are not the first in a series are considered independent. They are not
―linked‖ by a milestone relationship to any other milestone. Both users and the system can
create independent milestones during a project/case lifecycle.

     7.2.3.3.   Floating Date
This milestone ―floats‖ in time. Its date and time are defined by a relationship to another
milestone that occurs at a time prior to this milestone. Three supporting attributes must exist
for a floating milestone to occur: a related milestone, duration (between the related
milestones) and a time unit.

     7.2.3.4.   Incremental
This milestone does not have a fixed date. Like a floating milestone it is related to other
milestones but unlike a floating milestone, it does not have a time duration or unit assigned to
the relationship. This milestone does not have an expected achievement date, only an action
or actions indicating its achievement that may occur at any time. However, the milestone
may only be achieved if the related milestones that precede it have already been achieved.




Version 1.1                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                    Resource Data, Inc
                                             89
Resource Authorization System (RAS)
System Design


     7.2.4. Achieving Milestones
We have defined a milestone as a significant event in the case lifecycle. Milestones can only
be achieved by the user taking an action. When a milestone is achieved, there are several
things that may happen:
     Clocks started and stopped
     Phases change
     Notifications sent
     Related milestones added (and appropriate scheduled notifications)
Again, the only way a milestone can be achieved is by a user taking an action created to
achieve that milestone. For example, a milestone is added indicating a request for additional
information (RFAI). This milestone may have several clock impacts associated with it –
stopping the case clock and starting an RFAI clock.

     7.2.5. Notifications
Milestones will also make frequent use of the notifications sub-module. Notifications may be
attached to a milestone and sent either upon achievement, upon due date reached in the case
timeline (accounting for clocks), or by a period of time before the due date.

     7.2.6. Milestone Relationships
All the milestones in a related series, excluding the first milestone, are floating or
incremental. Each milestone in the series is related to the milestone before it. In the case of
floating milestones, the actual date and time each milestone in the series falls on is
determined by taking the date of the first milestone in the series (the fixed milestone) and
calculating the difference based on defined time durations.

                        1   10 days   2   12 days       3   24 days         4


In the diagram above, the red dot represents a fixed milestone, the first in a series that
includes 4 milestones and 3 relationships. The blue dots represent floating milestones and
the yellow arrows indicate the expected duration and time unit between them.
Another method for forming relationships between milestones involves the incremental class
of milestones. Since these milestones do not have an expected time period that will elapse
between them, they are only bound to actions and the requirement that the preceding
milestones must be achieved before they can be achieved.

                        1             2             3       4               5


In the diagram above, the red dot represents a fixed milestone, the first in a series that
includes 5 milestones and 4 relationships. The green dots represent incremental milestones
and the yellow arrows indicate the relationships (prerequisite milestones) between them.




Version 1.1                                                     9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                       Resource Data, Inc
                                              90
Resource Authorization System (RAS)
System Design


It is possible to mix milestone classes in a single series and more than one series can be
associated with a case. While independent milestones do not exist in series, they too may be
related to a case that is already related to one or many milestone series.

                            1     5 days         2                  3                  4     30 days      5


In the diagram above, the series includes fixed (red), floating (blue) and incremental
milestones (green). In this example, the first milestone would have its date set by the action
that indicated its achievement. The second milestone would be expected to be achieved 5
days after the first. The third and fourth would be achieved by user actions but have no
expected date for their achievement. The 5th milestone is expected to be achieved 30 days
after the 4th.
As a footnote to this example, the fact that a floating relationship exists between milestones
does not necessarily indicate that the time period must pass before the milestone may be
achieved. As with all milestones, the execution of a certain action will trigger the
achievement of the milestone. In some cases, the milestone may be achieved at any time
before or after the expected time period elapses. In these cases, system messaging would
alert users to the fact that the allotted time period has passed or not been achieved.
                                                                Time




                    Series A      1        10 days        2a    12 days           3a          24 days             4a
                                       5
                                        da
                                            ys




                    Series B                         2b                 3b                   4b    30 days        5




                    Independent         1             2                       3                               4




The diagram above illustrates 2 milestone series and 4 independent, fixed date milestones all
related to the same case. Both series begin with a single milestone (red 1). While starting
with a single milestone is possible, it is not required. Some milestones series may exist as
completely independent series, not sharing individual milestones between them.
In yet another example of mixing milestone series, a single series may branch, follow
independent sets of milestones and then join back together at a single milestone related to
both branches.


              1   10 days   2         12 days             3         24 days            4                24 days        5



                                             3b                         4b




Version 1.1                                                                                9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                  Resource Data, Inc
                                                               91
Resource Authorization System (RAS)
System Design


The diagram above illustrates the concept of milestone series branching. As with previous
examples, the red dot indicates the first, fixed milestone. The blue dots represent floating
milestones while the green dots represent incremental milestones. A twist on the typical
milestone class that is introduced here involves milestone 5. It exists as both a floating
milestone and an incremental milestone. The system would be responsible for ensuring that
its requirements (milestones 4 and 4b) have been met before allowing an action that would
indicate its achievement.

      7.2.7. Repeating Milestones
As a case moves through the typical lifecycle milestones, events may occur that require the
user to move back, or repeat, a milestone series. The system supports this kind of activity by
allowing users to enter actions that indicate their desire to repeat the achievement of a past
milestone. From a technical point-of-view, repeating milestones is only possible on pre-
defined (―template‖) milestones and results in a set of milestones being inserted into the
timeline rather than the same milestones being ―achieved‖ a second time.




                           1       10 days     2   12 days            3             24 days             4



The green arrow in the above diagram illustrates the result of a user taking an action that
triggers the achievement of milestone 2 even after they have already achieved every
milestone up to 4. By taking this action, they have moved back in the timeline. Another way
of illustrating the same concept is shown in the diagram below.

  1    10 days   2   12 days   3         24 days   4              2       12 days   3         24 days       4    24 days     5


When the series illustrated above is followed to completion (the achievement of milestone 5),
a review of the path that was taken to get to the final milestone reveals a repeat of milestones
2-4. This repeat was achieved by repeating the execution of actions that trigger milestones
that have already been achieved. The system is being designed to alert users when they are
about to move back in the timeline, but it will not prevent them from doing so.
Note that there is NO ability to ‗erase‘ an action that affects a milestone. A subsequent
action may affect milestones in ways that negate previous actions, but the prior actions
remain in the record. A good analogy to this is general ledger transactions – you can never
erase a transaction against the general ledger, but you can enter new transactions that balance
our, or negate, the results of a prior transaction.

      7.2.8. Consistency Review Example
The diagram below illustrates the milestones defined for a typical Consistency Review for
Federal Authorizations. While other elements of the Timeline structure are integral to this
process, only the milestones and their relationships are illustrated in this example.


Version 1.1                                                                             9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                               Resource Data, Inc
                                                             92
Resource Authorization System (RAS)
System Design


                                                                    8                            9                                          11
                                                                                                                                       ys
                                                                                                                                  da
                                                                   30 days                                                    5

                      21 days                                                    44 days                                           6d (day 50)
 1            2                 3           4                                                                            10                      12


                                                              25
                                                                   day
                                                                         s

                                                                                                                Initial Milestone




                                                  3d
                                                   ay
                                                                                                                Incremental Milestone




                                                    s
                                                                    5                      7
                                                                                                                Floating Milestone
                                                                                                                Milestone Relationship
                                                          6


This diagram references milestones common to one example of the consistency review
process. The numbers displayed atop each of the milestone symbols represent one of the
following business milestones for this process example:

      1. Project Initiated
      2. Application Received
      3. Application Accepted
      4. Review Started
      5. Request for Additional Information
      6. Info Packet Distributed
      7. RFAI Period Ended
      8. Public Comment Request Received
      9. Public Comment Ended
      10. Proposed Determination Issued
      11. Request for Elevation Received
      12. Final Determination Issued

      7.2.9. Land Use Permit Example
The diagram below illustrates the milestones defined for a typical Land Use Permit review
process. While other elements of the Timeline structure are integral to this process, only the
milestones and their relationships are presented below.


  1               2                 3                                        6                        7              8                           9


                                                10 days                                                     Initial Milestone
                                        4                 5
                                                                                                            Incremental Milestone
                                                                                                            Floating Milestone
                                                                                                            Milestone Relationship


The diagram references milestones common to the Land Use Permit review process. The
numbers displayed atop each of the milestone symbols represent one of the following
business milestones for this process example:

      1. Case started
Version 1.1                                                                                    9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                      Resource Data, Inc
                                                          93
Resource Authorization System (RAS)
System Design


     2.   Application received
     3.   Case initiated
     4.   Public notice
     5.   Public notice complete
     6.   Decision to issue
     7.   Permit issued
     8.   Close case request
     9.   Case closed

7.3.      Actions
Within the RAS Architecture, an Action is defined as any official activity taken on the case
file during its lifecycle. May or may not indicate the achievement of a milestone.

     7.3.1. Business Definition
Throughout the business processes of both MLW and OPMP there exists the concept of
users, typically adjudicators, taking actions on the case file as it progresses through its
lifecycle. A valid action can be as simple as a phone conversation or as complex as issuing a
final consistency finding. An action may be defined as anything a user does during their
regular business day that has any effect on a case file.

     7.3.2. System Definition
Actions can be thought of as a running log of what has been accomplished on a case file.
From the system design perspective, the list of potential actions a user can enter into the
―action log‖ is relatively large. For this reason, all the actions available in the system are
stored in an ―action library‖.
Technically speaking, to support the concept of an Action Library each potential action is
stored as a record in the Case Action Type database entity. When an action is taken in
reference to a specific case, a record is created in the Case Action entity along with direct
attributes and related records in associated entities (Case Action Type, Clock Impact,
Contact, Document, etc.).
Valid actions in the system can be broken down into several classes. The action classes exist
to logically group the actions by scope.

     7.3.3. Action Classes
There are several classes defined for actions. A single action may belong to one or many of
the classes listed below.

     7.3.3.1.    Standard (Non-Impact)
A standard action is one that does not have an impact on any other component of the system.
These are the most simple actions a user or the system can take. Typically, these actions
have minimal additional data requirements and are only reported against when viewing the
complete case action log.

Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                              94
Resource Authorization System (RAS)
System Design


Actions that belong to the Standard, Non-Impact class may not belong to any other action
class except User or System. Examples of this class include: phone conversations, client
meetings, etc.

     7.3.3.2.   Achievement
An achievement action is one that indicates the achievement of a milestone. When this
action is taken, among other potential data requirements, one or many milestones are marked
as being achieved.
An indirect relationship exists between actions in this class and phase changes. A phase may
be defined as a time period between two related milestones. Actions are the only method that
may indicate the achievement of a milestone. In this way, actions taken by a user or by the
system may have an impact on the phase through the achievement of milestones.

     7.3.3.3.   Document
A Document action is one that requires the user or system to include at least one reference to
a digital document with the action data. Typically, actions in this class make reference to
documents that were sent or received by the user or system.

     7.3.3.4.   Notification
A Notification action is one that results in notifications (e-mail, fax, etc) being sent to one or
many contacts.

     7.3.3.5.   User
A User action is one that is committed by a standard system user. In addition to belonging to
one of the above classes, all actions are either User or System actions.

     7.3.3.6.   System
A System action is one that is committed by the system without user intervention or
assistance. In addition to belonging to one of the above classes, all actions are either User or
System actions.

     7.3.3.7.   Status
A status action is one that results in the status of the case being changed.

     7.3.4. Action Log
The action log is a listing of all the actions taken on a case. The system has been designed to
allow specific users the ability to access the action log at any time. With their tight
integration into the timeline, individual actions in the action log may be quickly and easily
used to cross-reference milestones.




Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                              95
Resource Authorization System (RAS)
System Design


     7.3.5. Action Library
All actions that are possible are loaded into the action library (records in the action_type
entity). When a user executes an action, they select it from the list and complete any
additional data that is required by the action.
The system may also execute an action (record it in the action log) based on user activity on
the case (changing case description, changing case file location, changing case owner, etc.)
The list of viable actions available to users may be filtered based on the current phase and
case type. This means that the system may be setup to allow only certain types of actions if a
case is currently in a specific phase. Implementation of this feature is optional, but
recommended to keep the list of valid actions to a minimum and enforce business rules
around the execution of actions.

     7.3.6. Consistency Review Example
The Consistency Review process makes use of several actions that may be considered unique
to consistency reviews. However, some of these actions may be generalized enough to be
cross-case type compatible when RAS is implemented. The following is a table of actions
for a typical Consistency Review for Federal Authorizations:


 Pre-application Contact                      Evaluate RFAI
 Create Project                               Request Additional Info from Applicant
 Create Case                                  Receive RFAI response from Applicant
 Record Project Notes                         Determine if RFAI resp is adequate
 Abandon Project                              Notification of Adequate Information
 Receive Application                          Receive Request for Public Hearing
 Record Case Notes                            Notify Requestor of Public Hearing
 Determine Application Incomplete             Notify Requestor of PH Denial
 Abandon Case                                 Issue Notice of Public Hearing
 Receive Amended Application                  Hold Public Hearing
 Determine Application Complete               Distribute PH Summary of Comments
 Determine Start Date                         Stop Clock (various reasons)
 Notify Applicant                             Notify Applicant and Agency of Status
 Issue Public Notice                          Issue Proposed Determination
 Notify Review Participants                   Issue Final Determination
 Receive RFAI from Agency/District


Version 1.1                                                   9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                     Resource Data, Inc
                                              96
Resource Authorization System (RAS)
System Design


     7.3.7. Land Use Permit Process Example
While many of the case types in RAS will share similar action types, some action types may
be defined with a specific case type or group of case types in mind. The following list of
example action types may contain entries that appear similar to the Consistency Review
action types, but many are still largely specific to the Land Use Permit process due to their
specific attributes when implemented:


 Change Case Status                               Final Decision Made
 Request Information From Agency                  Accept Application
 Receive Information From Agency                  Initiate Case
 Request Information From Applicant               Issue Permit
 Receive Information From Applicant               Close Case
 Public Notice                                    Submit Inspection Report
 Preliminary Decision                             Conduct Agency Review

7.4.      Phases
A phase is one of the special-use labels for the time period between two milestones. The
period itself may cover more than two milestones, but the beginning and ending of a phase
are marked by a distinct beginning milestone and a distinct ending milestone.

     7.4.1. Business Definition
From the business perspective, a phase is a quick indication of the schedule status of the case.
There are pre-defined phases used for each case type. These beginning and ending points for
the phases are linked directly to milestones. Therefore, when a user takes an action that
triggers the achievement of a milestone, a phase may begin, end or continue.
Certain specific phases have already been defined for some of the initial case types to be
loaded into the system.

         Pre-Application
         Application (Application Review)
         Public Review (optional)
         Adjudication
         Issuance
         Monitoring and Compliance
         Closeout
Further definition of the individual phases is available in the requirements documentation
prepared as a prerequisite of this document.


Version 1.1                                                       9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                         Resource Data, Inc
                                             97
Resource Authorization System (RAS)
System Design


     7.4.2. System Definition
The system defines a phase in simple terms as a look-up value for the period between two
milestones. The phase value is always current based on the milestones that have been
achieved up to any point. The diagram below illustrates this concept.


             Related Milestones



         1        10 days         2        12 days         3   24 days    4           24 days         5     6 days   6


                    Time Unit
              Duration
                                            Phase
      Milestone

              Pre-Application         Application Review                      Adjudication




If a user, or the system, was to need to know the current phase for a case, they would access a
call that would determine the phase based on the sequence of actions taken during the
lifecycle of the case. Some of the actions taken triggered the achievement of milestones.
The last milestone to be achieved will indicate the current phase the case is in. For example,
in the above diagram, if actions have been taken to indicate the achievement of milestone 4
(blue 4), the system will determine that the case is in the adjudication phase.
For another example, if the last milestone to be achieved was milestone 2 (blue 2), but 20
days had gone by since the achievement of milestone 2, the system would determine that the
current phase is Application Review. The system may be configured to automatically submit
the action required to achieve milestone 3 after 12 days expired, but for this example we will
assume it is not configured in this manner. Regardless of the amount of time that has elapsed
after a milestone was achieved, the phase will remain the same until a phase-changing
milestone is achieved. The phase-changing milestones in the diagram above are 1, 2, 3 and
6.

     7.4.3. Examples
A typical consistency review process might include the following phases (in order):
     Pre-Application
     Application Review
     Adjudication
     Determination
     Elevation
A typical land use permit review process might include the following phases (in order):
     Pre-Application
     Application
     Adjudication
     Issuance
     Monitoring and Compliance

Version 1.1                                                                        9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                          Resource Data, Inc
                                                                     98
Resource Authorization System (RAS)
System Design


         Close-Out
In both sets of example phases, the first 3 phases are nearly identical with pre-application,
application and adjudication phases in both sets. However, as indicated by the unique
business processes represented, the phases following adjudication are much different
depending on the major case type divisions (OPMP vs. ML&W). Case Types utilized by the
Division of Mining, Land and Water have a significant interest in post-issuance activity and
monitoring while the Office of Project Management and Permitting lacks this business
requirement.

7.5.      Clocks
Within the RAS architecture, clocks are similar to phases in that they have a beginning and
ending milestone. However, clocks can be started and stopped in between these two
milestones and provide critical information about how the system interprets the time between
the beginning and ending milestones.

     7.5.1. Business Definition
From a business perspective, a clock is defined as a way to track the number of business days
(days the clock is on) a certain milestone has to be completed. For the OPMP, clocks serve
as the calendar and deadline rules around which they operate. Some clocks are as long as 6
months (federal) while others last only 14 days (request for additional information, RFAI,
clock). If the project is not complete by the end of the project review clock period, it is
automatically presumed consistent.
Many clocks do not exist on a 1:1 relationship with a regular calendar. Rather, a clock, as it
is defined in this system, has the ability to be started and stopped as a result of milestones
being achieved. The total number of ―on‖ days may be accumulated to give the temporal
status of a consistency review at any time during the review process.

     7.5.2. System Design
In the RAS system design, clocks are defined as a component of the case module. At the
lowest level, clocks are supported directly by two database tables, Clock and Clock_Impact.
An individual clock is represented as a record in the Clock entity. Impacts (clock on, clock
off) on individual clock records are stored as records in the Clock_Impact entity. These
entities are directly related to cases and milestones.

     7.5.2.1.   Case Relationship
The scope of any clock is bound to a parent case. Without a case, the clock has no reason for
existing. From a business perspective, the clock brings definition to the calendar around
which a consistency review (case) is executed.
An individual case may have several clocks associated with it, but one clock may not be
associated with multiple cases. A clock type (50-day review, 14-day RFAI, etc) may be
implemented across several cases, but individual implementations of each may not relate to
multiple cases.

Version 1.1                                                 9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                   Resource Data, Inc
                                             99
Resource Authorization System (RAS)
System Design


     7.5.2.2.         Milestone Relationship
Clocks are related to certain milestones that indicate when a clock begins and ends (is
extinguished). The achievement (through action) of one of these clock-related milestones
indicates a clock impact (start or stop) occurs.

     7.5.3. Multiple Clocks
The diagram below illustrates the existence of several clocks during a consistency review
process.
                              Application Request           Info           App
                    Actions    Received     Info          Received       Accepted



              Clock Impacts     Start          Stop           Start          Stop


        Clock (max time)                       CPQ Clock (21-day)


              Clock Impacts                                                  Start


        Clock (max time)                                                                        Review Clock (50-day)
          Clock Impacts         Start          Stop           Start

        Clock (max time)                                                             Federal Review Clock (90-day)

                                         3d            4d              4d
      Actual Clock Time                 “on”          “off”           “on”

                                                                                           Actions TimeLine



This diagram also illustrates how a single milestone may have an impact to more than one
clock. Furthermore, the impacts may be to different clocks in opposite ways, stopping one,
while at the same time, starting another.
Yet another concept present in the diagram above is the actual time vs. the max time of a
clock. Milestones reveal the amount of time that elapsed between clock starts and stops. In
the diagram, the actual clock ―on‖ time adds up to 7 days even though the clock is set for 21
days. This is an acceptable outcome. Should the number of days exceed the clock‘s ―max
time‖, the notifications system will alert the user that they have exceeded the normally
allotted time.

     7.5.4. Clock Matching (Multiple Stops or Starts in Sequence)
In addition to impacting many clocks at once, multiple milestones may have the same impact
on a single clock. It is not necessarily true that all clock impacts will be immediately
followed by an opposite impact (every stop is not always followed by a start). It is possible
to have a situation where a single clock could be impacted by more than one stop based on
the actions taken by a user. When this event occurs, the clock may be restarted only when all
related milestones with start impacts have been achieved.




Version 1.1                                                                                                    9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                                      Resource Data, Inc
                                                                                     100
Resource Authorization System (RAS)
System Design




                            Start    Stop   Stop        Start       Start

                                            CPQ Clock (21-day)



In the diagram above, a single clock is impacted 5 times. The beginning start impact,
illustrated by the first green arrow, has initiated the clock. The first stop impact, illustrated
by the first red arrow, has an immediate effect of stopping the clock. It is followed by a
second stop impact (gray arrow). The second stop impact has no immediate effect on the
clock due to the clock already being stopped. The next clock impact, illustrated by the
second gray arrow, registers as a clock start impact. This particular milestone has a clock
start that satisfies the second (gray) stop. However, the clock may not re-start because a stop
is still in effect in response to the first stop milestone. Only after the last start impact has
been entered (final green arrow), indicating a milestone satisfying the first stop, may the
clock resume.



                            Start    Stop   Stop        Start       Start

                                            CPQ Clock (21-day)



The above diagram illustrates the same concept, but with a slightly different combination of
clock on and off events. Regardless of the relationship between the multiple stop events, the
clock may not restart until all of the pending stops have been satisfied through specific
actions.

     7.5.5. Consistency Review Example
In the case of consistency reviews, the clock concept is rather straight-forward and highly
integrated into their already established business practices. The following example illustrates
the use of clocks during a Consistency Review for Federal Authorizations.




Version 1.1                                                      9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                        Resource Data, Inc
                                               101
Resource Authorization System (RAS)
System Design




                                                                               R
                                                                                eq
                                                                                    ue
        D




                                          D




                                                                                       st
         et




                                            et




                                                                                                                                                                                                                                       Is
                                                                                                                                                                                                        St
                              R
           er




                                                                                         Ad
                                              er




                                                                                                                                                                                                                                          s
                               ec




                                                                                                                                                                                                          op
               m




                                                                                                                                                                                                                                            ue
                                                                                            d
                                                m




                                                                                                                                                                                                                            R




                                                                                                                                                                                                                                                            Is
                                  ei
                in




                                                                                             iti




                                                                                                                                            Pu



                                                                                                                                                            Pu




                                                                                                                                                                                                                             es
                                                                                                                                                                                                             C
                                                 in




                                                                                                                                                                                                                                                               s
                                   ve




                                                                                                                                                                                                                                               Pr
                   e




                                                                                              on




                                                                                                                                                                                                                                                               ue
                                                                                                                                                                                                               lo
                                                    e




                                                                                                                                               b



                                                                                                                                                               b




                                                                                                                                                                                                                                ta
                     Ap




                                                                                                                                                                                                                                                  o
                                                                                                                                                lic



                                                                                                                                                                lic
                                                                                                   al




                                                                                                                                                                                                                 ck
                                                                                                                                                                                                Su
                                       Am



                                                      Ap




                                                                                                                                                                                                                                                  po
       Ap




                                                                                                                                                                                                                                   r




                                                                                                                                                                                                                                                                   Fi
                                                                                                                                                                                     H




                                                                                                                                                                                                                                    ta
                                                                                                                  Ap
                                                                        St
                        p




                                                                                                                                   En
                                                                                                    In




                                                                                                                                                   R



                                                                                                                                                                    H




                                                                                                                                                                                                   m



                                                                                                                                                                                                                    at
                                                         p




                                                                                                                                                                                     ol




                                                                                                                                                                                                                                                      se



                                                                                                                                                                                                                                                                      n
                         lic
          p




                                          en




                                                                          ar




                                                                                                                                                                                                                                       tC
                                                                                                       fo




                                                                                                                                                      ev



                                                                                                                                                                      ea
                                                          lic




                                                                                                                     p




                                                                                                                                                                                                                                                                        al
                                                                                                                                                                                                     m
         lic




                                                                                                                                      d




                                                                                                                                                                                         d
                            at




                                                                                                                                                                                                                        C




                                                                                                                                                                                                                                                       d
                                                                                                                        lic
                                                                          tA
                                            de



                                                             at




                                                                                                                                                       ie




                                                                                                                                                                                                        ar
                                                                                                        fro




                                                                                                                                        of




                                                                                                                                                                        ri n



                                                                                                                                                                                         Pu
              at




                                                                                                                                                                                                                                                                          D
                                                                                                                                                                                                                                         lie
                                                                                                                                                                                                                        lie
                                                                                         Ev
                              io




                                                                                                                                                                                                                                                           D
                                                                                                                          an




                                                                                                                                                           w
                                                               io




                                                                                                                                                                                                                                                                           et
                                               d




                                                                                                                                                                                                           y
                                                                            C
                io



                                n




                                                                                                                                                                                                                                                           et
                                                                                                                                            R




                                                                                                                                                                           g




                                                                                                                                                                                                                                            nt
                                                                                                                                                                                                                            nt
                                                                                                            m




                                                                                                                                                                                            b
                                                                                            a
                                                                n




                                                                                                                                                                                                            D
                                                                               M




                                                                                                                              tR




                                                                                                                                                                                                                                                                             er
                                                 Ap
                n




                                                                                                                                                            R
                                                                                                                                            FA




                                                                                                                                                                                             lic
                                   In




                                                                                                                                                                                                                                                             er
                                                                                             lu




                                                                                                                                                                               to




                                                                                                                                                                                                                                              s
                                                                                                                                                                                                                              s
                                                                                                              Ap




                                                                                                                                                                                                               is
                                                                    C




                                                                                                                                                               eq
                                                                                P
                     R




                                                                                                                                                                                                                                                                               m
                                                                                                at
                                      c




                                                                                                                                                                                                                                                 R
                                                                                                                                                                                                                                R




                                                                                                                                                                                                                                                               m
                                                    p




                                                                                                                               es




                                                                                                                                                                                                                tri
                                                                                                                                                                                                H
                                                                                                                                                                                be
                                                                    om




                                                                                                                                              IP
                                     om
                     ec




                                                                                                                                                                                                                                                                                in
                                                                                   R
                                                    lic




                                                                                                                                                                                                                                                  eq
                                                                                                                                                                                                                                  eq
                                                                                                                 p
                                                                                                  e




                                                                                                                                                                ue




                                                                                                                                                                                                                                                                   in
                                                                                                                                                                                                   ea



                                                                                                                                                                                                                    b
                                                                                                                                   po
                                                                                                                  lic
                                                                                    ev




                                                                                                                                                                                                                                                                                   at
                         ei




                                                                                                                                                er
                                                                                                    R
                                                        at




                                                                                                                                                                                                                                                                    at
                                                                                                                                                                                                                    ut
                                                                                                                                                                                     H
                                                                        pl




                                                                                                                                                                                                                                                      ue
                                          pl




                                                                                                                                                                                                                                    ue
                                                                                                                                                                    st




                                                                                                                                                                                                    ri n




                                                                                                                                                                                                                                                                                     io
                                                                                                                     an
                         ve




                                                                                                      FA




                                                                                                                                    ns
                                                                                       ie




                                                                                                                                                                                     el
                                                          io




                                                                                                                                                      io




                                                                                                                                                                                                                                                                      io
                                                                         et




                                                                                                                                                                                                                      io
                                          et




                                                                                                                                                                      ed




                                                                                                                                                                                                                                                       st
                                                                                                                                                                                                                                       st




                                                                                                                                                                                                                                                                                     n
                                                                                         w




                                                                                                                                                                                         d
                                                           n




                                                                                                                                                       d




                                                                                                                                                                                                        g




                                                                                                                                                                                                                                                                        n
                                                                                                                                                                                                                        n
                                                                           e




                                                                                                                        t
                            d




                                                                                                                                        e
                                            e




                                                                                                        I
                                  CPQ                           CPQ                                                                                                            Review 50-day


                                                                                                                          Response                                                                          Summary                                                          Response
                                                                                                            Eval RFAI        7d                                                 7d                            5d                                                                5d




                                                                                                                                   RFAI 14d




                                                                                                                                             Project 90-day



                                                                                                                                            Federal 6-month



                                                                                                                                                Project Timeline




Several clock concepts are illustrated in the above diagram. For much of the process, three
clocks are active, the 50-day review clock (blue), the 90-day project clock (green) and the 6-
month federal clock (orange). Certain actions taken during the project process have the
effect of starting or stopping one of these clocks. Periods where the clock has been stopped
are represented by a shaded section of these three arrows.
Yellow arrows in the diagram represent clocks that are initiated by certain actions and
extinguished by others that are expected to follow shortly. These clocks typically cover only
a few days and are designed to ensure that the project continues to move forward by limiting
the number of days available for material reviews, responses, etc.

     7.5.6. Land Use Permitting Example
For the land use permitting process, the clock concept is not employed in as many facets of
the individual review tasks but it is still utilized to ensure the review project continues to
move toward completion. In the following diagram, a typical request for additional
information from an applicant is illustrated using the clock concept.
                                                                                                        C
                                                                                                            lie
                                                                                                                nt
                                                                                         Ad



                                                                                                                  R




                                                                                                                                                                        In
                                                                    Pe




                                                                                                                                                In
                                                                                                                     eq
                                                                                            d




                                                                                                                                                                           fo
                                                                                                                                                   fo
                                                                                                iti
                                                                       r




                                                                                                                            .I
                                                                          m




                                                                                                                                                                                R
                                                                                                   on




                                                                                                                                                       R
                                                                                                                              nf




                                                                                                                                                                                     ec
                                                                               it




                                                                                                                                                           ec
                                                                                                        al



                                                                                                                                o
                                                                                Ap




                                                                                                                                                                                         ei
                                                                                                                                                               ei
                                                                                                                                    Fr
                                                                                                            In




                                                                                                                                                                                             ve
                                                                                   p




                                                                                                                                                                ve
                                                                                                               fo



                                                                                                                                       o
                                                                                       lic




                                                                                                                                                                                              d
                                                                                                                                            m
                                                                                                                  r




                                                                                                                                                                      d
                                                                                                                  m
                                                                                            at




                                                                                                                                                                                                   Fr
                                                                                                                                                                         Fr
                                                                                                                                                O
                                                                                                                        at
                                                                                              io




                                                                                                                                                                                                      o
                                                                                                                                                 th



                                                                                                                                                                            o
                                                                                                n



                                                                                                                          io




                                                                                                                                                                                                        m
                                                                                                                                                                                m
                                                                                                                                                    e
                                                                                                                              n
                                                                                                    R




                                                                                                                                                       rA




                                                                                                                                                                                                            Ap
                                                                                                                                                                                     Ag
                                                                                                        ec



                                                                                                                               N
                                                                                                                                   ee




                                                                                                                                                                                                               p
                                                                                                                                                         ge
                                                                                                            ei




                                                                                                                                                                                        e



                                                                                                                                                                                                                    lic
                                                                                                                                                                                             nc
                                                                                                              ve



                                                                                                                                        de



                                                                                                                                                                 nc




                                                                                                                                                                                                                        an
                                                                                                                                                                                                y
                                                                                                                  d




                                                                                                                                                                      y
                                                                                                                                            d




                                                                                                                                                                                                                            t




                                                                                                                                                               10-day Response


                                                                                                                                                           Project Timeline




Version 1.1                                                                                                                                                                                  9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                                                                                                                    Resource Data, Inc
                                                                                                                                     102
Resource Authorization System (RAS)
System Design


In the above example, a single clock (blue arrow) is employed to track the amount of time
allocated for an applicant to respond to a request for additional information. During the
response period, the applicant has requested additional information from another state, local
or federal agency. At the time more information was requested of another agency, the clock
tracking the applicant‘s time to respond was stopped (shaded area). Upon receipt of
additional information from the agency, the applicant‘s response clock is re-started. When
the applicant responds to the request for additional information, the 10-day response clock is
extinguished.

7.6.      Overview Diagram of Actions, Milestones, Phases and Clocks
The following diagram ties many of the concepts from this document together in a single
example. While this diagram does not attempt to present a completely accurate case lifecycle
for either consistency reviews or land use permits, it does illustrate the concepts that can be
applied to case type timelines once they are loaded and configured within RAS.
Within the diagram, the following set of sample Milestones and Actions are referenced:

     7.6.1. Actions
1. Project Initiated, Pre-Application Action (MS 1) (Start Clock)
2. Contacted applicant with requested info
3. Received signed application (MS 2) (Start Clock)
4. Application tagged as complete
5. Fees received (MS 3) (Start Clock) (Stop Clock)
6. Customer Contact - Request Information (Stop Clock)
7. Customer Contact - Information Received (Start Clock)
8. Agency Comments Received (MS 4)
9. Customer Contact - Request Information (Stop Clock)
10. Customer Contact - Information Received (Start Clock)
11. Public Comments Received (MS 5) (Stop Clock)
12. Received Customer Info
13. Permit Issued (MS 6) (Stop Clock)
14. Fees Received
15. Issue Signed and Returned (MS 7)
16. Received Annual Report (MS 8)
17. Annual Report Received (MS 9)
18. Completion Report Received (MS 10)


Version 1.1                                                 9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                   Resource Data, Inc
                                             103
Resource Authorization System (RAS)
System Design


     7.6.2. Milestones
1. Project Initiated
2. Application Received
3. Application Officially Accepted for Review
4. Public Notice Initiated
5. Public Notice Ended
6. Permit Issued
7. Permit Signed/Returned
8. Annual Report Submitted
9. Completion Report Received
10. Permit Closed/Bond Returned




Version 1.1                                     9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                       Resource Data, Inc
                                         104
Resource Authorization System (RAS)
System Design


                                                                                                                     Time



    Action




      1            2            3                4           5       6       7       8              9          10    11     12   13              14   15                       16               17                        18


          Related Milestones



      1         10 days         2                            3                                 24 days                            6     8 days         7          1 year        8     10 days   9           10 days       10


                 Time Unit
           Duration
   Milestone
                                                                                     4               24 days          5
                                             Phase


             Pre-Application           Application Review                                    Adjudication                               Issue                              Monitor                          Close




                                                                                                   Stop     Start
                                                                                                                                                                                                            Legend
                               Start                                Stop    Start                                                Stop                 Start                    Stop

                                                                                                                                                                                                 15     Actions
                                                                           60 day decision clock                                                              1 year report
                                                                                                                                                                                                    1   Initiating Milestone
                                                            Start   Stop    Start                  Stop     Start    Stop
                                                                                                                                                                                                    2   Floating Milestone

                                                                              48 day review clock                                                                                                   3   Incremental Milestone

     Start                                                  Stop                                                                                                                                        Clock

                                                                                                                                                                                                        Milestone Relationship
               22 day pre-application clock                                         Start                            Stop
                                                                                                                                                                                                        Phase

                                                                                            24 day public comment                                                                                       Stop Clock

                                                                                                                                                                                                        Start Clock




Version 1.1                                                                                                                                      9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                                                                                                        Resource Data, Inc
                                                                                                                    105
Resource Authorization System (RAS)
System Design


8. External Interfaces
8.1.      GIS API
       Request          Parameters              Return            Notes/Comments

 Create Feature     Feature Class            Feature ID   It is expected that a geographic
 (from              Name                                  interface will be available for
 geographic         Feature                               "red-lining" of features. The
 interface)         [attribute/value list]                GIS should be capable of
                                                          accepting user input in the
                                                          form of features drawn within
                                                          such an interface and adding
                                                          them to a central project
                                                          feature class. The user should
                                                          be prompted to supply
                                                          peripheral attributes, but a
                                                          unique key should be
                                                          generated automatically and
                                                          stored in RAS.
 Create Point       Feature Class            Feature ID   Optional attribute/value list is
 Feature            Name                                  expected to contain field
 (from non-         X                                     (attribute) names and values to
 geographic         Y                                     be entered for the indicated
 interface)         [attribute/value list]                field.

 Create Line        Feature Class            Feature ID   Optional attribute/value list is
 Feature            Name                                  expected to contain field
 (from non-         Begin X                               (attribute) names and values to
 geographic         Begin Y                               be entered for the indicated
 interface)         End X                                 field.
                    End Y
                    [attribute/value list]
 Create             Feature Class            Feature ID   Optional attribute/value list is
 Minimum            Name                                  expected to contain field
 Bounding           Upper Right X                         (attribute) names and values to
 Rectangle          Upper Right Y                         be entered for the indicated
 (Polygon           Lower Left X                          field.
 Feature)           Lower Left Y
 (from non-         [attribute/value list]
 geographic
 interface)


Version 1.1                                               9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                 Resource Data, Inc
                                              106
Resource Authorization System (RAS)
System Design


       Request       Parameters           Return               Notes/Comments

 Show Basic      X                     Success/Fail    By default, view should
 Location Map    Y                                     include base map features for
 by Point        Scale                                 the location specified. The
                 [Project Features                     optional project features
                 on/off]                               parameter, if on, indicates that
                 [Feature Filter]                      all project features should be
                 [Feature Theme                        displayed as well. The
                 Classify]                             optional feature filter string
                                                       may provide an attribute,
                                                       operator, and value
                                                       combination to be applied to
                                                       the project feature class. The
                                                       optional theme classify string
                                                       accepts an attribute name for
                                                       theme classification - exact
                                                       values will be classified (no
                                                       graduated values).
 Get Basic       Upper Right X         Success/Fail    By default, view should
 Location Map    Upper Right Y                         include base map features and
 by Bounding     Lower Left X                          project/case features. The
 Points          Lower Left Y                          optional project features
                 [Project Features                     parameter, if on, indicates that
                 on/off]                               all project features should be
                                                       displayed as well.
 Get Basic       Feature ID            Success/Fail    By default, view should
 Project         [base feature list]                   include base map features and
 Location Map                                          the indicated project/case
                                                       feature(s).



 Get Areas of    X                     XML             By default, view should
 Concern by      Y                     document        include base map features and
 Coordinates     Scale                 containing      features from various "Areas
                 [displayed feature    features and    of Concern" feature classes.
                 classes]              attributes of   Optional "displayed feature
                                       "Areas of       classes" parameter allows
                                       Concern"        users to list the specific feature
                                       feature         classes from the "Areas of
                                       classes that    Concern" that should be
                                       intersect the   displayed. If not supplied, all


Version 1.1                                            9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                              Resource Data, Inc
                                        107
Resource Authorization System (RAS)
System Design


       Request         Parameters           Return               Notes/Comments
                                         project/case    "Areas of Concern" are
                                         feature(s).     displayed.




 Get Areas of      Feature ID            Success/Fail    View should include base map
 Concern by        [base feature list]                   features, project/case features
 Project           [buffer on/off]                       and features from various
                   [buffer distance]                     "Areas of Concern" feature
                                                         classes. Optional buffer
                                                         parameter indicates that a
                                                         buffer should be applied when
                                                         performing the spatial query.
                                                         If this parameter is set to "on",
                                                         the buffer distance parameter
                                                         must be supplied and indicates
                                                         the numeric distance (in a pre-
                                                         determined unit such as feet or
                                                         meters) of the buffer from the
                                                         boundaries of the project
                                                         feature(s).
 Get Areas of      Feature ID            XML             Optional buffer parameter
 Concern by        [buffer on/off]       document        indicates that a buffer should
 Feature           [buffer distance]     containing      be applied when performing
                                         features and    the spatial query. If this
                                         attributes of   parameter is set to "on", the
                                         "Areas of       buffer distance parameter must
                                         Concern"        be supplied and indicates the
                                         feature         numeric distance (in a pre-
                                         classes that    determined unit such as feet or
                                         intersect the   meters) of the buffer from the
                                         project/case    boundaries of the project
                                         feature(s).     feature(s).
 Select Projects   Upper Right X         XML             Feature IDs will be used to
 Geographically    Upper Right Y         document        retrieve project IDs in RAS.
                   Lower Left X          containing      Ideally, all feature IDs from
                   Lower Left Y          Feature IDs     the Project feature class will
                                         for the         exist as records in the location
                                         submitted       table within RAS.


Version 1.1                                              9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                Resource Data, Inc
                                          108
Resource Authorization System (RAS)
System Design


       Request        Parameters            Return                Notes/Comments
                                         geographic
                                         area.




 Update Project    Feature Class         Feature ID       Geographical method for
 Feature           Name                                   updating (red-line editing) a
                   Feature ID                             previously saved Project
                   Updated Feature                        feature in the Projects feature
                                                          class.

 Coordinate        X                     XML              Lat/Long parameter data in
 Conversion        Y                     document         decimal degrees.
 (non-             Original              containing X
 geographic        Coordinate System     and Y values.
 interface)        Original Horizontal
                   Datum
                   Original Vertical
                   Datum
                   Desired Coordinate
                   System
 Spatial Query     1st Feature Class     Success/Fail     Provides users the ability to
 with              Name                  XML              query for spatial features that
 Geographic or     [1st feature class    Document         intersect or overlap. Similar to
 XML Result        filter]               with Features    "Areas of Concern" spatial
 (Intersection/O   [1st feature class    and Attributes   query, but more general to
 verlap)           buffer distance]      that intersect   allow for Project overlap,
                   2nd Feature Class     and the          project/waterbody proximity,
                   Name                  intersection     etc. (adjudicator spatial
                   [2nd feature class    location         analysis). If no value is
                   filter]               (XML return      entered in the optional
                   [2nd feature class    format)          parameter "buffer distance", a
                   buffer distance]                       buffer will not be applied.
                   Return Format                          Buffer units will not be
                                                          selectable (fixed as feet or
                                                          meters).




Version 1.1                                               9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                 Resource Data, Inc
                                          109
Resource Authorization System (RAS)
System Design


       Request          Parameters                Return                Notes/Comments

 Identify Feature   Feature                 XML                Provides for retrieving RAS
                                            document           data about specific geographic
                                            containing         features (e.g., Projects, Areas
                                            attributes for     of Concern, District Plan
                                            selected           details, etc.).
                                            feature.
 Delete Feature     Feature ID              Success/Fail




 Get Map PDF        Upper Right X           PDF
 by Bounding        Upper Right Y
 Coordinates        Lower Left X
                    Lower Left Y
                    [feature list]
                    [feature filter]



8.2.      LAS: Revenue and Billing (R&B) Methods
The following are methods the LAS R&B system will make available to RAS.
financialStatus()
     Returns a table of summary information about the status of the account related to
       the case number

     Direction          Name                Type                          Description

In                  caseNumber         String                LAS file type + file number

Out                 financialStatus financialStatus          Summary information from R&B
                                                             about agreement




Version 1.1                                                     9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                       Resource Data, Inc
                                                110
Resource Authorization System (RAS)
System Design


paymentHistory()
    Returns information for a given date range about all payments received for a
     specific case


     Direction        Name               Type                      Description

In                caseNumber        String             LAS file type + file number

In                startDate         Datetime           Beginning date of filtered data

In                endDate           Datetime           Ending date for filtered data

In                dateSort          String             Sort date by ascending or
                                                       descending. Valid values are:
                                                           ASC
                                                           DESC

In                startRecord       Number             Record number to start payment
                                                       history

In                endRecord         Number             Record number of last payment
                                                       record to return

Out               paymentHistory collection of         Date and payment amount for
                                 paymentHistory        all transactions of given within
                                                       date range provided


paymentHistory()
    Returns information for all payments received for a specific LAS receipt type

     Direction        Name               Type                      Description

In                caseNumber        String             LAS file type + file number

In                dateSort          String             Sort date by ascending or
                                                       descending. Valid values are:
                                                           ASC
                                                           DESC

In                startRecord       Number             Record number to start payment

Version 1.1                                              9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                Resource Data, Inc
                                             111
Resource Authorization System (RAS)
System Design


                                                      history

In                endRecord      Number               Record number of last payment
                                                      record to return

Out               paymentHistory collection of        Date and payment amount for all
                                 paymentHistory       transactions of given receipt
                                                      type


setupAgreement()
     Adds a reccurring payment to R&B

     Direction            Name                 Type                 Description

In               caseNumber           String            LAS file type + file number

In               agreementType        String            Type of agreement; valid
                                                        values are:
                                                             Lease
                                                             Permit

In               termPeriod           String            Sets the time period payments
                                                        apply to. Valid values are:
                                                             Monthly
                                                             Annual
                                                             Semi-annual
                                                             Quarterly

In               termLength           Integer           Length of term in months

In               amount               Currency          Payment amount due each
                                                        period

In               firstPaymentDueDate Date               Date when first payment is
                                                        due




Version 1.1                                             9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                               Resource Data, Inc
                                         112
Resource Authorization System (RAS)
System Design


8.3.      RAS Methods for R&B
The following are methods RAS will make available to the LAS R&B system.
feeReceived()
    Updates RAS that a fee has been received in R&B. This will most typically be
      used when an application fee is received through the PIC rather than online. RAS
      will continue processing the application once the fee has been recorded as being
      received in RAS.

     Direction        Name              Type                      Description

In                caseNumber      String             LAS file type + file number


reportVisitorCount()
    Submits the recorded visitor count to RAS for reporting

     Direction        Name              Type                      Description

In                caseNumber      String             LAS file type + file number

In                Count           Integer            Number of visitors


cashBondReceived()
    Notifies RAS that a cash bond has been received for the case

     Direction        Name              Type                      Description

In                caseNumber      String             LAS file type + file number

In                Amount          Currency           Amount of cash bond received

In                dateReceived    Datetime           Date the cash bond was received
                                                     by DNR




Version 1.1                                              9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                Resource Data, Inc
                                            113
Resource Authorization System (RAS)
System Design


8.4.      LAS: Customer Information System (CIS) Methods
updateCaseCustomer()
    Submits a newly added RAS contact to LAS

     Direction          Name           Type                    Description

In                caseNumber      String          LAS file type + file number

In                customerInfo    customerInfo    Customer information

In                addressInfo     collection of   Contact‘s case addresses
                                  addressInfo

In                phoneInfo       collection of   Contact‘s case telephone
                                  phoneInfo       numbers

In                emailInfo       collection of   Contact‘s case emails
                                  emailInfo

In                caseContactType String          Role of contact for the case

Out               CID             String          Customer ID in CIS




Version 1.1                                          9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                            Resource Data, Inc
                                       114
Resource Authorization System (RAS)
System Design



updateCaseCustomer()
    Submits an updated RAS contact to LAS

     Direction         Name              Type                   Description

In               caseNumber        String          LAS file type + file number

In               customerInfo      customerInfo    Customer information

In               addressInfo       collection of   Contact‘s case addresses
                                   addressInfo

In               phoneInfo         collection of   Contact‘s case telephone
                                   phoneInfo       numbers

In               emailInfo         collection of   Contact‘s case emails
                                   emailInfo

In               caseContactType String            Role of contact for the case

In               CID               String          Customer ID in CIS



8.5.      LAS: Case Management (CM)
updateCase()
    Submits a new case to CM

     Direction       Name             Type                      Description

In               caseInfo       caseInfo           Case information

Out              caseNumber     String             LAS file type + file number


updateCase()
    Updates an existing case in CM with new case information

     Direction       Name             Type                      Description



Version 1.1                                           9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                             Resource Data, Inc
                                         115
Resource Authorization System (RAS)
System Design



In                 caseInfo        caseInfo           Case information

In                 caseNumber      String             LAS file type + file number


addCaseAction()
    Submits a new action associated with an existing case to CM

     Direction        Name               Type                      Description

In                 actionType      String             Type of action in CM

In                 actionText      String             Text to update CM with for the
                                                      action

In                 caseNumber      String             LAS file type + file number


addCaseLocation()
    Submits a new location associated with an existing case to CM

     Direction        Name               Type                      Description

In                 MTRS            collection of      Location in MTRS
                                   MTRS

In                 legalDesc       String             Legal Description

In                 caseNumber      String             LAS file type + file number



8.6.      Online Credit Card Processing
All online credit card transaction will be processed through the DNR EFT client. Please
refer the DNR EFT Client documentation for more information.




Version 1.1                                               9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                 Resource Data, Inc
                                            116
Resource Authorization System (RAS)
System Design


8.7.      LDAP Employee Directory
isValidUser()
    Verifies if the user is a valid State of Alaska employee

     Direction          Name               Type                      Description

In                  username         String             LDAP username

In                  password         String             Encrypted string

Out                 isValidUser      Boolean            True = valid user
                                                        False = not a valid user, access
                                                        denied



8.8.      Logging
Use of Logging within the RAS Application
The following description of logging within the RAS Application may be considered a
supplement to the IT Requirements document deliverable 1.5.
DNR has chosen Log4J as its logging tool for java applications. Logging is beneficial for
debugging and tracking activity occurring within an application. Log4j is well
documented on the internet. The following provides general guidelines for using logging
within the RAS project.
Log message content – Log output should include the threshold level, date, time, and
active thread of the event being logged as well as information from the operational or
business process being logged.
Log threshold – The contractor can set an appropriate logging threshold (e.g. DEBUG,
INFO, WARN, ERROR, FATAL). The external configuration file will automatically
activate log statements based on the threshold level set in the configuration file.
DNR is requesting that logging be used in the following areas -
Debugging – DNR assumes that any software received from the contractor will be free of
known software problems. Delivered code to DNR may include debug logging when the
contractor feels this is appropriate for testing at DNR. The contractor is encouraged to
leave debug log statements within code that is considered complex. DNR will accept
software with debug log statements stored in software. The contractor will choose which
debug statements are left in place when code is delivered.




Version 1.1                                                9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                  Resource Data, Inc
                                              117
Resource Authorization System (RAS)
System Design


System Messaging – the following are representative of system messaging events that
are typically logged:
Session start
Session end
Session timeout
Database connections
Application saved
Email message transmitted
Business Process – the following are representative of business process events that are
typically logged:
Actions
Milestones
Clock activities
Add or update contact information
Add or update case information
Add new documents
Add or update location information
Add or update security
Add or update rule information
Add new application
Add or update grant
Security login
Security logout




Version 1.1                                                9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                  Resource Data, Inc
                                           118
Resource Authorization System (RAS)
System Design



9. Standards
9.1.      Coding standards and naming conventions
All Java code will follow Sun‘s recommended coding standards located at:
http://java.sun.com/docs/codeconv/.




Version 1.1                                              9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                Resource Data, Inc
                                          119
Resource Authorization System (RAS)
System Design



10. Glossary
  Term / Acronym                                       Definition
                     Alaska Administrative Code. Also known as ―regulations,‖ the AAC has the
AAC                  force of law. State agencies and other administrative bodies write regulations to
                     interpret and add specificity to Alaska Statutes.
                     Alaska Coastal Management Act. Passed by the Legislature in 1977, the ACMA
ACMA                 provides the basis for the Alaska Coastal Management Program.
                     Alaska Coastal Management Program. The program Alaska developed under
ACMP                 the federal Coastal Zone Management Act to manage coastal resources and uses
                     within its coastal zone. The ACMP received federal approval in 1979.
ADC                  Alaska Data Center

AKSAS                Alaska Statewide Accounting System
                     Areas which Merit Special Attention. A specific area designated under the
                     Alaska Coastal Management Program that is sensitive to change or alteration,
AMSA                 and possesses unique physical, cultural, or biological characteristics. More
                     specifically defined in: AS 46.40.210(1) and 6 AAC 80 Article 4.
                     Alaska National Interest Lands Conservation Act. A federal law that provided
                     significant additions to federally owned and managed conservation system
ANILCA               units. Designations included additions to national parks, national forests,
                     wildlife refuges, and wilderness areas.
ANSI                 American National Standards Institute

API                  Application Programming Interface

AS                   Alaska Statute. These are the laws passed by the Alaska Legislature.

ASP                  Active Server Pages

CC                   Credit Card Payment System

CCPS                 Credit Card Processing System

CDD                  Conceptual Design Document

CIC                  Computer Information Center

CIS                  Customer Information System
                     Same as district. A municipality, borough, city, or CRSA that contains a portion
Coastal District     of the coastal area of the state. Paraphrased from AS 46.40.210(2).
                     U.S. Army Corps of Engineers, or Corps. The Corps designs and constructs
                     military projects for the Army and Air Force and civil projects, such as harbors,
COE                  for coastal communities. The Corps also regulates development in navigable
                     waters (Section 10 of the Rivers and Harbors Act of 1899), and placement of fill
                     material in waters and wetlands (Section 404 of the Clean Water Act).




Version 1.1                                                     9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                       Resource Data, Inc
                                             120
Resource Authorization System (RAS)
System Design


  Term / Acronym                                        Definition
                      A finding concerning consistency with the statewide Standards and enforceable
                      policies of the ACMP. For projects affecting the coastal zone, a consistency
                      determination is required for permits issued by state and federal agencies and
Consistency           for activities conducted by or for a federal agency. A consistency determination
determination         contains a brief description of a project and the findings of the consistency
                      review, including any stipulations and justification for the stipulations. More
                      specifically defined in: 6 AAC 50.190(9).
                      Evaluation of a proposed project against the statewide Standards and
Consistency review    enforceable policies of a coastal district.
Consistent to the     Federal government activities or uses, including projects affecting the coastal
maximum extent        zone, must be consistent with the statewide Standards and enforceable policies
practicable           of the ACMP unless compliance would violate another federal law.
                      The state agency responsible for coordinating and facilitating a consistency
Coordinating agency   review and rendering a consistency determination.
                      Coastal Policy Council. The Council provides overall direction for the Alaska
Council               Coastal Management Program as delegated by the Legislature in the ACMA.
CPC                   Coastal Policy Council. See Council.
                      Coastal Project Questionnaire. The required form for initiating a project
CPQ                   consistency review and determining which permits a project requires.
CRP                   Commercial Recreation Permit
                      Coastal Resource Service Area. An area of the unorganized borough established
CRSA                  and organized to form a coastal district. See also AS 29.03.020 and AS
                      46.40.110 to 46.40.180.
CRUD                  Standard database operations – create (C), read (R), update (U), delete (D)
                      Coastal States Organization. A group of coastal state representatives formed to
CSO                   work on coastal issues common among the states.
                      Conservation System Unit. Federal lands with special designation. These
CSU                   include wilderness areas, national parks and preserves, national forests, and
                      national wildlife refuges.
CVS                   Concurrent Versions System

CZ                    Coastal zone
                      Federal Coastal Zone Management Act of 1972. Creates the national coastal
CZMA                  zone management program that provides national guidance and direction for
                      creating individual state coastal management programs.
DB                    Database

DBA                   Database Administrator
                      Alaska Department of Commerce and Economic Development. Promotes and
DCED                  regulates economic activities within Alaska.
                      Alaska Department of Community and Regional Affairs. Promotes development
DCRA                  and provides assistance to communities, municipalities, and rural areas of
                      Alaska.
DDS                   Detailed Design Specification

DEC                   Alaska Department of Environmental Conservation. Protects and regulates the


Version 1.1                                                      9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                        Resource Data, Inc
                                               121
Resource Authorization System (RAS)
System Design


  Term / Acronym                                            Definition
                         public health and environment.
                         Alaska Department of Fish and Game, or ADF&G. Manages fish and wildlife
DFG                      species and their habitats.
                         Alaska Division of Governmental Coordination, under the Office of the
DGC                      Governor. The administrative seat of the Alaska Coastal Management Program.
DIO                      Database Interface Object

Direct and significant   See Use of Direct and Significant Impact.
impact
                         Same as coastal district. A municipality, borough, city, or CRSA that contains a
District                 portion of the coastal area of the state. Paraphrased from AS 46.40.210(2).
DMLW                     Division Of Mining, Land, and Water

DNR                      Dept. of Natural Resources

DOA                      Dept. of Administration
                         Alaska Department of Transportation and Public Facilities. Manages Alaska‘s
DOT&PF                   transportation infrastructure and public facilities.
EFT                      Electronic Funds Transfer

EPA                      Federal Environmental Protection Agency.

ESRI                     Environmental Systems Research Institute, Inc.

FN                       file number - a number assigned to an application, up to 12 digits in size

FT                       file type - an abbreviated identifier for a type of authorization; i.e. LUP

FTP                      File Transfer Protocol
                         Fiscal Year. The State of Alaska‘s fiscal year begins July 1 and ends June 30.
FY                       The federal government‘s fiscal year begins October 1 and ends September 30.
GIS                      Geographic Information System
                         The direction in 6 AAC 85 for development of district coastal management
Guidelines               programs adopted by the Coastal Policy Council. The Guidelines include
                         content and program approval requirements.
HTTP                     Hypertext Transfer Protocol

IEEE                     Institute of Electrical and Electronics Engineers, Inc.

IT                       Information Technology

ITG                      Information Technology Group

JSP                      JavaServer Pages

LAS                      Land Administration System

LDAP                     Lightweight Directory Access Protocol
                         A body of knowledge or information about the coastal environment, including
                         information passed down through generations, from individual and group
Local Knowledge          experience and observations. The local community generally accepts this body
                         of knowledge. Paraphrased from 6 AAC 85.900(16).



Version 1.1                                                          9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                            Resource Data, Inc
                                                  122
Resource Authorization System (RAS)
System Design


  Term / Acronym                                       Definition

LRIS                 Division of Support Services, Land Records Information Section

LUP                  Land Use Permit

MAR                  Multiple agency review

Mitigate             To lessen an adverse impact or moderate its severity.
                     National Environmental Policy Act of 1969. Requires consideration of
NEPA                 environmental effects for activities conducted or authorized by federal agencies.
                     National Estuarine Research Reserve System. A federal program established
NERRS                under the CZMA to designate representative estuaries throughout the country
                     for research purposes. Katchemak Bay is the only NERR in Alaska.
NTSRS                Non-Technical Software Requirements Specification
                     Federal Office of Ocean and Coastal Resource Management, National Oceanic
OCRM                 and Atmospheric Administration, U.S. Department of Commerce. Administers
                     and promotes the federal coastal zone management program.
                     Outer continental shelf. Generally, submerged lands under the jurisdiction of the
                     federal government lying seaward of state boundaries. State boundaries
OCS                  ordinarily occur three miles seaward of the coastline. Further defined in Section
                     2 of the Submerged Lands Act, 43 U.S.C. Section 1301.
                     Portable Document Format (a universal document format from Adobe Systems,
PDF                  Inc.)
                     A permit, lease, authorization, license or any other determination necessary for
Permit               completion of a project or discrete phase of a project. 6 AAC 50.190(13).
PERT                 Program Evaluation and Review Technique

POC                  Point of contact (designated person in one of the DMLW regional offices)
                     An activity or use located in or that may affect the coastal zone Paraphrased
Project              from: 6 AAC 50.190(14).
                     A documented need of the general public and not that of any private individual
Public Need          or group of individuals. Paraphrased from 6 AAC 85.900(21).
R&B                  Revenue & Billing System

RAPS                 Resource Authorization Processing System
                     Special Area Management Plan. A plan approved by the Coastal Policy Council
SAMP                 that addresses a small area or specific resource or use.
SAR                  Single agency review
                     Section 10 of the federal Rivers and Harbors Act of 1899. Regulates
                     construction activities in and adjoining navigable waters that alter the course,
Section 10           condition, location, or capacity of such waters. Provides permitting authority for
                     structures in navigable waters.
                     Section 306 of the federal Coastal Zone Management Act of 1972. Authorizes
Section 306          grants to states for administration and amendments to their coastal management
                     programs.
                     Section 309 of the federal Coastal Zone Management Act of 1972. Authorizes
Section 309          coastal zone enhancement grants for making changes to state coastal zone
                     management programs that meet enhancement objectives.



Version 1.1                                                     9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                       Resource Data, Inc
                                             123
Resource Authorization System (RAS)
System Design


  Term / Acronym                                           Definition
                       Section 401 of the Clean Water Act (Federal Water Pollution Control Act).
                       Provides for states (DEC in Alaska) to certify to federal permitting agencies that
Section 401            discharges into navigable waters will comply with applicable provisions of the
                       Clean Water Act.
SG                     Status Graphics (status plat)

SOAP                   Simple Object Access Protocol
                       When a use or activity located outside the coastal zone may have a direct and
Spillover              significant impact on coastal resources or uses inside the coastal zone.
SPUR                   Status plat update request

SQL                    Standard Query Language

SRS                    Software Requirements Specification
                       The standards for coastal development adopted by the Coastal Policy Council in
Statewide Standards    6 AAC 80.
                       A design strategy that divides an application into three layers or "tiers." In the
                       typical three-tier architecture, the first tier is persistent data storage. The second
Three-Tier             tier is the business logic layer. This is where the rules regarding the stored data
Architecture.          are represented. This will be the bulk of our application. The third tier is
                       presentation enabling users to see the results of the DNR business logic applied
                       to the stored data
TSRS                   Technical Software Requirements Specification

UML                    Unified Modeling Language
                       A use that contributes to a change in the natural or social characteristics of a
Use of direct and      part of the state‘s coastal area. Such a use outside the coastal zone may still be
significant impact     subject to the ACMP and consistency review process. Paraphrased from AS
                       46.40.210(5).
Use of state concern   Those land and water uses that would significantly affect the long-term
                        A database that holds a superset of data derived from mainframe LAS. This is
Warehouse              a transitional database allowing updates between the mainframe and the system
                       under development.
XML                    Extensible Markup Language




Version 1.1                                                         9f188de7-1e95-4d75-895e-808af0b28d4a.doc
                                                                                           Resource Data, Inc
                                                124

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:7/23/2011
language:English
pages:124