ST-JNIA-02 JNIA CDC WDAC

**Use Case Specification: ST-JNIA-02: JNIA CDC**

Version \<1.8\>

Revision History

  ----------------- ------------- --------------------------- -----------------
  **Date**          **Version**   **Description**             **Author**

  23 March 2005     1.0           Initial Delivery            Don Cook

  8 June 2005       1.1           Updates requirements from   Stephanie
                                  WERRB                       Hunteman

  15 December       1.2           Final                       Stephanie
                                                              Hunteman

  20 April 2006     1.3           Mod 9 Update                Chuck Meier

  8 August 2006     1.4           Added special requirement   John Schuncke,
                                  to paragraph 1.2.2.3.6      Jr.

  26 February 2007  1.5           Added Info and Ready        Steve Sizer
                                  Product use case flows      
                                  developed under Increment 3 
                                  Mod 11                      

  15 May 2007       1.6           Mod 11 Use Case Updates.    Tom Jackson
                                  Removed data ingest and     
                                  monitor & control           
                                  functionality into separate 
                                  System Threads. Updated SSS 
                                  requirements traceable to   
                                  TRDs in embedded            
                                  spreadsheet at bottom of    
                                  document.                   

  13 June 2007      1.7           Deleted 5 SSS requirements  Tom Jackson
                                  (JNIASSS163, JNIASSS164,    
                                  JNIASSS165, JNIASSS166,     
                                  JNIASSS167) in the embedded 
                                  SSS Requirements            
                                  spreadsheet and moved them  
                                  to the METOC Import ST.     

  10 September 2007 1.8           Updated ST to match changes Tom Jackson
                                  to the B-Level UCs          
  ----------------- ------------- --------------------------- -----------------

Table of Contents

1\. ST-JNIA-02: JNIA CDC [1](#st-jnia-02-jnia-cdc)

1.1 CDC Product Build thru Dissemination
[1](#cdc-product-build-thru-dissemination)

1.1.1 Basic Description [1](#basic-description)

1.1.2 Product Build and Dissemination
[2](#product-build-and-dissemination)

1.1.2.1 Product Tailoring [2](#product-tailoring)

1.1.2.1.1 Actors [3](#actors)

1.1.2.1.2 Preconditions [3](#preconditions)

1.1.2.1.3 Post Conditions [3](#post-conditions)

1.1.2.1.4 Basic Flow Steps [3](#basic-flow-steps)

1.1.2.1.5 Alternate Flow Steps [3](#alternate-flow-steps)

1.1.2.1.6 Special Requirements [3](#special-requirements)

1.1.2.2 Build Gridded INFO and READY Products
[3](#build-gridded-info-and-ready-products)

1.1.2.2.1 Actors [4](#actors-1)

1.1.2.2.2 Preconditions [4](#preconditions-1)

1.1.2.2.3 Post Conditions [4](#post-conditions-1)

1.1.2.2.4 Basic Flow Steps [4](#basic-flow-steps-1)

1.1.2.2.5 Alternate Flow Steps [5](#alternate-flow-steps-1)

1.1.2.2.6 Special Requirements [5](#special-requirements-1)

1.1.2.3 Build Catalog Product [5](#build-catalog-product)

1.1.2.3.1 Actors [5](#actors-2)

1.1.2.3.2 Preconditions [5](#preconditions-2)

1.1.2.3.3 Post Conditions [6](#post-conditions-2)

1.1.2.3.4 Basic Flow Steps [6](#basic-flow-steps-2)

1.1.2.3.5 Alternate Flow Steps [6](#alternate-flow-steps-2)

1.1.2.3.6 Special Requirements [6](#special-requirements-2)

1.1.2.4 Build Event Based JMBL Products
[6](#build-event-based-jmbl-products)

1.1.2.4.1 Actors [6](#actors-3)

1.1.2.4.2 Preconditions [7](#preconditions-3)

1.1.2.4.3 Post Conditions [7](#post-conditions-3)

1.1.2.4.4 Basic Flow Steps [7](#basic-flow-steps-3)

1.1.2.4.5 Alternate Flow Steps [7](#alternate-flow-steps-3)

1.1.2.4.6 Special Requirements [7](#special-requirements-3)

1.1.2.5 Build Period Based JMBL Products
[7](#build-period-based-jmbl-products)

1.1.2.5.1 Actors [8](#actors-4)

1.1.2.5.2 Preconditions [8](#preconditions-4)

1.1.2.5.3 Post Conditions [8](#post-conditions-4)

1.1.2.5.4 Basic Flow Steps [8](#basic-flow-steps-4)

1.1.2.5.5 Alternate Flow Steps [9](#alternate-flow-steps-4)

1.1.2.5.6 Special Requirements [9](#special-requirements-4)

1.1.2.6 Disseminate METOC Product [9](#disseminate-metoc-product)

1.1.2.6.1 Actors [10](#actors-5)

1.1.2.6.2 Preconditions [10](#preconditions-5)

1.1.2.6.3 Post Conditions [10](#post-conditions-5)

1.1.2.6.4 Basic Flow Steps [10](#basic-flow-steps-5)

1.1.2.6.5 Alternate Flow Steps [10](#alternate-flow-steps-5)

1.1.2.6.5.1 Dissemination request failed.
[10](#dissemination-request-failed.)

1.1.2.6.6 Special Requirements [11](#special-requirements-5)

1.1.2.7 Startup and Recovery of Expanded Dissemination Capability.
[11](#startup-and-recovery-of-expanded-dissemination-capability.)

1.1.2.7.1 Actors [11](#actors-6)

1.1.2.7.2 Preconditions [11](#preconditions-6)

1.1.2.7.3 Post Conditions [12](#post-conditions-6)

1.1.2.7.4 Basic Flow Steps [12](#basic-flow-steps-6)

1.1.2.7.5 Alternate Flow Steps [12](#alternate-flow-steps-6)

1.1.2.7.5.1 EDC cannot evaluate its internal queues.
[12](#edc-cannot-evaluate-its-internal-queues.)

1.1.2.7.5.2 EDC cannot connect to DCD request queue.
[12](#edc-cannot-connect-to-dcd-request-queue.)

1.1.2.7.6 Special Requirements [12](#special-requirements-6)

1.2 CDC GUI [12](#cdc-gui)

1.2.1 Basic Description [12](#basic-description-1)

1.2.2 Manage User and Product Data [13](#manage-user-and-product-data)

1.2.2.1 Manage User Data [13](#manage-user-data)

1.2.2.1.1 Actors [13](#actors-7)

1.2.2.1.2 Preconditions [14](#preconditions-7)

1.2.2.1.3 Post Conditions [14](#post-conditions-7)

1.2.2.1.4 Basic Flow Steps [14](#basic-flow-steps-7)

1.2.2.1.5 Alternate Flow Steps [14](#alternate-flow-steps-7)

1.2.2.1.6 Special Requirements [14](#special-requirements-7)

1.2.2.2 Manage Region Definitions [14](#manage-region-definitions)

1.2.2.2.1 Actors [15](#actors-8)

1.2.2.2.2 Preconditions [15](#preconditions-8)

1.2.2.2.3 Post Conditions [15](#post-conditions-8)

1.2.2.2.4 Basic Flow Steps [15](#basic-flow-steps-8)

1.2.2.2.5 Alternate Flow Steps [15](#alternate-flow-steps-8)

1.2.2.2.5.1 User Edits an Existing Region
[15](#user-edits-an-existing-region)

1.2.2.2.5.2 User Deletes an Existing Region
[15](#user-deletes-an-existing-region)

1.2.2.2.6 Special Requirements [16](#special-requirements-8)

1.2.2.3 Define Child Products - GUI [16](#define-child-products---gui)

1.2.2.3.1 Actors [16](#actors-9)

1.2.2.3.2 Preconditions [16](#preconditions-9)

1.2.2.3.3 Post Conditions [16](#post-conditions-9)

1.2.2.3.4 Basic Flow Steps [16](#basic-flow-steps-9)

1.2.2.3.5 Alternate Flow Steps [17](#alternate-flow-steps-9)

1.2.2.3.6 Special Requirements [17](#special-requirements-9)

1.2.2.4 Define Parent Products - GUI [17](#define-parent-products---gui)

1.2.2.4.1 Actors [18](#actors-10)

1.2.2.4.2 Preconditions [18](#preconditions-10)

1.2.2.4.3 Post Conditions [18](#post-conditions-10)

1.2.2.4.4 Basic Flow Steps [18](#basic-flow-steps-10)

1.2.2.4.5 Alternate Flow Steps [19](#alternate-flow-steps-10)

1.2.2.4.6 Special Requirements [19](#special-requirements-10)

1.2.2.5 Edit Products [19](#edit-products)

1.2.2.5.1 Actors [19](#actors-11)

1.2.2.5.2 Preconditions [20](#preconditions-11)

1.2.2.5.3 Post Conditions [20](#post-conditions-11)

1.2.2.5.4 Basic Flow Steps [20](#basic-flow-steps-11)

1.2.2.5.5 Alternate Flow Steps [20](#alternate-flow-steps-11)

1.2.2.5.6 Special Requirements [20](#special-requirements-11)

1.2.2.6 Define JMBL Products [20](#define-jmbl-products)

1.2.2.6.1 Actors [21](#actors-12)

1.2.2.6.2 Preconditions [21](#preconditions-12)

1.2.2.6.3 Post Conditions [21](#post-conditions-12)

1.2.2.6.4 Basic Flow Steps [21](#basic-flow-steps-12)

1.2.2.6.5 Alternate Flow Steps [22](#alternate-flow-steps-12)

1.2.2.6.5.1 Text Entry of JMBL Request for Product
[22](#text-entry-of-jmbl-request-for-product)

1.2.2.6.5.2 JMBL Request Fails Validation
[22](#jmbl-request-fails-validation)

1.2.2.6.5.3 JMBL Request Returns No Data
[22](#jmbl-request-returns-no-data)

1.2.2.6.6 Special Requirements [23](#special-requirements-12)

1.2.2.7 Edit JMBL Products [23](#edit-jmbl-products)

1.2.2.7.1 Actors [23](#actors-13)

1.2.2.7.2 Preconditions [23](#preconditions-13)

1.2.2.7.3 Post Conditions [24](#post-conditions-13)

1.2.2.7.4 Basic Flow Steps [24](#basic-flow-steps-13)

1.2.2.7.5 Alternate Flow Steps [24](#alternate-flow-steps-13)

1.2.2.7.6 Special Requirements [24](#special-requirements-13)

1.2.2.8 Delete Products [24](#delete-products)

1.2.2.8.1 Actors [25](#actors-14)

1.2.2.8.2 Preconditions [25](#preconditions-14)

1.2.2.8.3 Post Conditions [25](#post-conditions-14)

1.2.2.8.4 Basic Flow Steps [25](#basic-flow-steps-14)

1.2.2.8.5 Alternate Flow Steps [26](#alternate-flow-steps-14)

1.2.2.8.6 Special Requirements [26](#special-requirements-14)

1.2.2.9 MOC Setup [26](#moc-setup)

1.2.2.9.1 Actors [26](#actors-15)

1.2.2.9.2 Preconditions [26](#preconditions-15)

1.2.2.9.3 Post Conditions [26](#post-conditions-15)

1.2.2.9.4 Basic Flow Steps [26](#basic-flow-steps-15)

1.2.2.9.5 Alternate Flow Steps [27](#alternate-flow-steps-15)

1.2.2.9.6 Special Requirements [27](#special-requirements-15)

1.2.2.10 Manage Subscription Data [27](#manage-subscription-data)

1.2.2.10.1 Actors [27](#actors-16)

1.2.2.10.2 Preconditions [27](#preconditions-16)

1.2.2.10.3 Post Conditions [27](#post-conditions-16)

1.2.2.10.4 Basic Flow Steps [27](#basic-flow-steps-16)

1.2.2.10.5 Alternate Flow Steps [27](#alternate-flow-steps-16)

1.2.2.10.6 Special Requirements [28](#special-requirements-16)

1.2.2.11 Load Catalog Products [28](#load-catalog-products)

1.2.2.11.1 Actors [28](#actors-17)

1.2.2.11.2 Preconditions [28](#preconditions-17)

1.2.2.11.3 Post Conditions [28](#post-conditions-17)

1.2.2.11.4 Basic Flow Steps [28](#basic-flow-steps-17)

1.2.2.11.5 Alternate Flow Steps [28](#alternate-flow-steps-17)

1.2.2.11.6 Special Requirements [28](#special-requirements-17)

1.2.2.12 Add Catalog Subscription [29](#add-catalog-subscription)

1.2.2.12.1 Actors [29](#actors-18)

1.2.2.12.2 Preconditions [30](#preconditions-18)

1.2.2.12.3 Post Conditions [30](#post-conditions-18)

1.2.2.12.4 Basic Flow Steps [30](#basic-flow-steps-18)

1.2.2.12.5 Alternate Flow Steps [30](#alternate-flow-steps-18)

1.2.2.12.6 Special Requirements [31](#special-requirements-18)

1.2.2.13 Edit Catalog Subscription [31](#edit-catalog-subscription)

1.2.2.13.1 Actors [31](#actors-19)

1.2.2.13.2 Preconditions [31](#preconditions-19)

1.2.2.13.3 Post Conditions [32](#post-conditions-19)

1.2.2.13.4 Basic Flow Steps [32](#basic-flow-steps-19)

1.2.2.13.5 Alternate Flow Steps [32](#alternate-flow-steps-19)

1.2.2.13.6 Special Requirements [32](#special-requirements-19)

1.2.2.14 Delete Subscription to a Product
[32](#delete-subscription-to-a-product)

1.2.2.14.1 Actors [33](#actors-20)

1.2.2.14.2 Preconditions [33](#preconditions-20)

1.2.2.14.3 Post Conditions [33](#post-conditions-20)

1.2.2.14.4 Basic Flow Steps [33](#basic-flow-steps-20)

1.2.2.14.5 Alternate Flow Steps [33](#alternate-flow-steps-20)

1.2.2.14.6 Special Requirements [33](#special-requirements-20)

1.2.2.15 Enter Legacy Filename Tokens
[33](#enter-legacy-filename-tokens)

1.2.2.15.1 Actors [34](#actors-21)

1.2.2.15.2 Preconditions [34](#preconditions-21)

1.2.2.15.3 Post Conditions [34](#post-conditions-21)

1.2.2.15.4 Basic Flow Steps [34](#basic-flow-steps-21)

1.2.2.15.5 Alternate Flow Steps [34](#alternate-flow-steps-21)

1.2.2.15.5.1 The Remote Filename contains one or more invalid or
malformed tokens.
[34](#the-remote-filename-contains-one-or-more-invalid-or-malformed-tokens.)

1.2.2.15.6 Special Requirements [34](#special-requirements-21)

1.2.2.16 Add Endpoint [34](#add-endpoint)

1.2.2.16.1 Actors [35](#actors-22)

1.2.2.16.2 Preconditions [35](#preconditions-22)

1.2.2.16.3 Post Conditions [35](#post-conditions-22)

1.2.2.16.4 Basic Flow Steps [35](#basic-flow-steps-22)

1.2.2.16.5 Alternate Flow Steps [36](#alternate-flow-steps-22)

1.2.2.16.6 Special Requirements [36](#special-requirements-22)

1.2.2.17 Modify Endpoint [36](#modify-endpoint)

1.2.2.17.1 Actors [37](#actors-23)

1.2.2.17.2 Preconditions [37](#preconditions-23)

1.2.2.17.3 Post Conditions [37](#post-conditions-23)

1.2.2.17.4 Basic Flow Steps [37](#basic-flow-steps-23)

1.2.2.17.5 Alternate Flow Steps [37](#alternate-flow-steps-23)

1.2.2.17.6 Special Requirements [37](#special-requirements-23)

1.2.2.18 Delete Endpoint [37](#delete-endpoint)

1.2.2.18.1 Actors [38](#actors-24)

1.2.2.18.2 Preconditions [38](#preconditions-24)

1.2.2.18.3 Post Conditions [38](#post-conditions-24)

1.2.2.18.4 Basic Flow Steps [38](#basic-flow-steps-24)

1.2.2.18.5 Alternate Flow Steps [39](#alternate-flow-steps-24)

1.2.2.18.6 Special Requirements [39](#special-requirements-24)

1.3 Command Line Utilities [39](#command-line-utilities)

1.3.1 Define Gridded INFO or READY Products
[39](#define-gridded-info-or-ready-products)

1.3.1.1 Actors [39](#actors-25)

1.3.1.2 Preconditions [39](#preconditions-25)

1.3.1.3 Post Conditions [40](#post-conditions-25)

1.3.1.4 Basic Flow Steps [40](#basic-flow-steps-25)

1.3.1.5 Alternate Flow Steps [40](#alternate-flow-steps-25)

1.3.1.6 Special Requirements [40](#special-requirements-25)

1.3.2 Manage INFO or READY Product Subscription
[40](#manage-info-or-ready-product-subscription)

1.3.2.1 Actors [41](#actors-26)

1.3.2.2 Preconditions [41](#preconditions-26)

1.3.2.3 Post Conditions [41](#post-conditions-26)

1.3.2.4 Basic Flow Steps [41](#basic-flow-steps-26)

1.3.2.5 Alternate Flow Steps [41](#alternate-flow-steps-26)

1.3.2.5.1 A "?" is Entered for Product Name field
[41](#a-is-entered-for-product-name-field)

1.3.2.6 Special Requirements [41](#special-requirements-26)

1.4 Management GUI [41](#management-gui)

1.4.1 Basic Description [41](#basic-description-2)

1.4.2 Manage User Data [42](#manage-user-data-1)

1.4.2.1 Actors [42](#actors-27)

1.4.2.2 Preconditions [42](#preconditions-27)

1.4.2.3 Post Conditions [43](#post-conditions-27)

1.4.2.4 Basic Flow Steps [43](#basic-flow-steps-27)

1.4.2.4.1 Alternate Flow Steps [43](#alternate-flow-steps-27)

1.4.2.4.2 Special Requirements [43](#special-requirements-27)

1.4.3 Manage Routes [43](#manage-routes)

1.4.3.1 Add a Route [43](#add-a-route)

1.4.3.1.1 Actors [44](#actors-28)

1.4.3.1.2 Preconditions [44](#preconditions-28)

1.4.3.1.3 Post Conditions [44](#post-conditions-28)

1.4.3.1.4 Basic Flow Steps [44](#basic-flow-steps-28)

1.4.3.1.5 Alternate Flow Steps [45](#alternate-flow-steps-28)

1.4.3.1.6 Special Requirements [45](#special-requirements-28)

1.4.3.2 Edit a Route [45](#edit-a-route)

1.4.3.2.1 Actors [46](#actors-29)

1.4.3.2.2 Preconditions [46](#preconditions-29)

1.4.3.2.3 Post Conditions [46](#post-conditions-29)

1.4.3.2.4 Basic Flow Steps [46](#basic-flow-steps-29)

1.4.3.2.5 Alternate Flow Steps [46](#alternate-flow-steps-29)

1.4.3.2.6 Special Requirements [46](#special-requirements-29)

1.4.3.3 Delete a Route [46](#delete-a-route)

1.4.3.3.1 Actors [47](#actors-30)

1.4.3.3.2 Preconditions [47](#preconditions-30)

1.4.3.3.3 Post Conditions [47](#post-conditions-30)

1.4.3.3.4 Basic Flow Steps [47](#basic-flow-steps-30)

1.4.3.3.5 Alternate Flow Steps [48](#alternate-flow-steps-30)

1.4.3.3.6 Special Requirements [48](#special-requirements-30)

1.4.4 Manage Endpoint Routing [48](#manage-endpoint-routing)

1.4.4.1 Add Endpoint Routing [48](#add-endpoint-routing)

1.4.4.1.1 Actors [49](#actors-31)

1.4.4.1.2 Preconditions [49](#preconditions-31)

1.4.4.1.3 Post Conditions [49](#post-conditions-31)

1.4.4.1.4 Basic Flow Steps [50](#basic-flow-steps-31)

1.4.4.1.5 Alternate Flow Steps [50](#alternate-flow-steps-31)

1.4.4.1.6 Special Requirements [50](#special-requirements-31)

1.4.4.2 Edit Endpoint Routing [50](#edit-endpoint-routing)

1.4.4.2.1 Actors [51](#actors-32)

1.4.4.2.2 Preconditions [51](#preconditions-32)

1.4.4.2.3 Post Conditions [51](#post-conditions-32)

1.4.4.2.4 Basic Flow Steps [52](#basic-flow-steps-32)

1.4.4.2.5 Alternate Flow Steps [52](#alternate-flow-steps-32)

1.4.4.2.6 Special Requirements [52](#special-requirements-32)

1.4.4.3 Delete Endpoint Routing [53](#delete-endpoint-routing)

1.4.4.3.1 Actors [53](#actors-33)

1.4.4.3.2 Preconditions [54](#preconditions-33)

1.4.4.3.3 Post Conditions [54](#post-conditions-33)

1.4.4.3.4 Basic Flow Steps [54](#basic-flow-steps-33)

1.4.4.3.5 Alternate Flow Steps [54](#alternate-flow-steps-33)

1.4.4.3.6 Special Requirements [54](#special-requirements-33)

2\. Requirements [54](#__RefHeading___Toc177456322)

**Use Case Specification: ST-JNIA-02: JNIA CDC**

# ST-JNIA-02: JNIA CDC

The JNIA CDC is comprised of three distinct threads which interact with
the same CSCIs, but in different ways and in an asynchronous manner. As
such, the distinct threads are summarized within this System Thread Use
Case, but the use case is divided into three distinct sections: 1. CDC
Product Build thru Dissemination; 2. CDC GUI; and 3. Management GUI. The
general inputs, outputs, preconditions, and post conditions for all four
sections are specified in following high-level figure.

![](media/image1.wmf)

Figure 1.1 JNIA CDC General Parameters

## CDC Product Build thru Dissemination

### Basic Description

This thread of the JNIA CDC documents the tailoring of METOC products
along with how they are built and the activities which are performed to
disseminate a METOC Product following receipt of a product ready
message. JMBL and Catalog Products are built based upon specified events
or time criteria, along with the receipt of messages to build a product.

![](media/image2.wmf) Figure 1.1.1.1 JNIA Product Build Thru
Dissemination Process Flow

### Product Build and Dissemination

#### Product Tailoring

![](media/image3.wmf){width="5.000694444444444in" height="2.025in"}

##### Actors

1.  Product Tailoring

2.  Data Access Layer

3.  Database

4.  Distribution

5.  Enterprise Notification

6.  Infrastructure

##### Preconditions

1.  Database is available.

2.  Product definition is available.

3.  Required product data available.

##### Post Conditions

1.  The product has been created.

2.  Distribution has received notification of the new product.

##### Basic Flow Steps

1.  This use case begins when a product assembly request message is
    received.

2.  The inbound product data is passed to JMCAT to retrieve data for
    dependant products.

3.  JMCAT returns the product dependency and definition data.

4.  The dependent products are assembled. The product is marked with the
    security level of the system on which the product was created.

5.  If an ad-hoc product, the JMBL request is submitted.

6.  The dynamic product data for newly assembled products is updated in
    JMCAT.

7.  Product available message and a product dissemination message are
    posted.

8.  Use case ends.

##### Alternate Flow Steps

> None.

##### Special Requirements

> None.

#### Build Gridded INFO and READY Products

This use case flow describes the activities required to build INFO and
READY products.

The data producer creates the INFO products for parent data product.
JNIA builds INFO products for gridded child products. JNIA builds all
READY products.

![](media/image4.wmf){width="6.236805555555556in" height="3.5in"}

##### Actors

1.  Product Tailoring

2.  Data Access Layer

3.  Database

4.  Enterprise Notification

5.  Infrastructure

##### Preconditions

1.  Gridded data is being ingested or child products created.

2.  Parent INFO data is being ingested.

3.  Subscription to INFO or READY product is entered and active.

##### Post Conditions

1.  The INFO or READY product has been created.

2.  Product Update request has been posted.

3.  The product build statistics data have been delivered.

4.  Action logged in Enterprise Notification.

##### Basic Flow Steps

1.  This use case may be triggered by one of two events: Product build
    messages are posted following the receipt of the parent INFO product
    or the receipt of the last product in a subscribed series of
    products from a single model run.

2.  Product Tailoring retrieves the dependant product definition
    information from Database via the Data Access Layer.

3.  The Data Access Layer returns the product definitions for INFO and
    READY products for the current model run for which subscriptions are
    active.

4.  Product Tailoring assembles the Gridded INFO and/or READY product in
    accordance with the product definition.

5.  Product Tailoring posts a Product Update Request for each product
    created.

6.  Product Tailoring delivers a product build statistic message to
    Infrastructure.

7.  This use case ends when Product Tailoring logs the product build and
    update notification actions via the Enterprise Notification.

##### Alternate Flow Steps

> None.

##### Special Requirements

1.  The system shall prevent duplicate shipment of the INFO and READY
    products created by the two possible asynchronous trigger events.

#### Build Catalog Product

This use case describes the process of building a Catalog Product.

![](media/image5.wmf){width="6.496527777777778in"
height="3.7152777777777777in"}

##### Actors

1.  Product Tailoring

```{=html}
<!-- -->
```
1.  Data Access Layer

2.  Database

3.  Infrastructure

4.  Enterprise Notification

##### Preconditions

1.  A request to start building one or more Catalog Products is
    received.

```{=html}
<!-- -->
```
1.  The data required to fulfill the definition of the Catalog Product
    is available.

```{=html}
<!-- -->
```
1.  The Catalog Product is defined in JMCAT

##### Post Conditions

1.  The Catalog Product has been built.

```{=html}
<!-- -->
```
1.  Statistic notifications for build have been posted.

```{=html}
<!-- -->
```
1.  Product update request has been posted.

2.  Action logged in Enterprise Notification.

##### Basic Flow Steps

1.  This use case begins when Product Tailoring requests the product
    definition(s) from Data Access Layer.

2.  Data Access Layer requests the product definition from Database.

3.  Database provides the product definition to the Data Access Layer.

4.  Data Access Layer provides the product definition to Product
    Tailoring.

5.  Product Tailoring builds the product in accordance with the product
    definition.

6.  Product Tailoring posts a Product Update Request for the product
    that was built.

7.  Product Tailoring sends a product build statistics entry for the
    product to Infrastructure.

8.  This use case ends when Product Tailoring logs the product build and
    update status notification actions via the Enterprise Notification.

##### Alternate Flow Steps

None.

##### Special Requirements

1.  Only products that have active subscriptions shall be built.

#### Build Event Based JMBL Products

This use case flow begins when a message is received to build an event
based JMBL product.

![](media/image6.wmf){width="5.991666666666666in"
height="3.140972222222222in"}

##### Actors

1.  Product Tailoring

2.  Data Access Layer

3.  Database

4.  Warrior Pull

5.  Distribution

6.  Enterprise Notification

7.  Infrastructure

##### Preconditions

1.  All actors are available.

```{=html}
<!-- -->
```
1.  Stored JMBL request message exists.

2.  METOC data which initiates an event trigger is being ingested.

##### Post Conditions

1.  The METOC product has been created.

2.  Distribution has received notification of the new product.

3.  Infrastructure has been updated with statistical data.

##### Basic Flow Steps

1.  This use case begins when an event triggers Product Tailoring to
    start building an event based JMBL product.

```{=html}
<!-- -->
```
1.  Product Tailoring retrieves the stored JMBL request from the Data
    Access Layer.

2.  Data Access Layer queries the Database for the JMBL request.

3.  Database provides JMBL request to the Data Access Layer.

4.  Data Access Layer returns JMBL request to Product Tailoring.

5.  Product Tailoring submits the JMBL request to Warrior Pull for
    product retrieval.

6.  Warrior Pull returns a response containing a reference to the
    product to Product Tailoring.

7.  Product Tailoring alerts Distribution that the product is available.

8.  Product Tailoring logs the product build and dissemination
    notification actions via the Enterprise Notification.

9.  This use case ends when a statistics message is sent to
    Infrastructure.

##### Alternate Flow Steps

> None.

##### Special Requirements

None.

#### Build Period Based JMBL Products

This use case describes the process of building a period based JMBL
product.

![](media/image7.wmf){width="5.991666666666666in"
height="3.3201388888888888in"}

##### Actors

1.  Product Tailoring

2.  Data Access Layer

3.  Database

4.  Warrior Pull

5.  Distribution

6.  Enterprise Notification

7.  Infrastructure

##### Preconditions

1.  All actors are available

```{=html}
<!-- -->
```
1.  Stored JMBL request exists in Database.

2.  METOC data is being ingested.

##### Post Conditions

1.  The METOC product has been created.

```{=html}
<!-- -->
```
1.  Distribution has received notification of the new product.

2.  Infrastructure has been updated with statistical data.

##### Basic Flow Steps

1.  This use case begins when a timer initiates a JMBL request within
    Product Tailoring.

```{=html}
<!-- -->
```
10. Product Tailoring retrieves the stored JMBL request message from the
    Data Access Layer.

11. Data Access Layer queries the Database for the JMBL request.

12. Database provides JMBL request to the Data Access Layer.

13. Data Access Layer returns JMBL request to Product Tailoring.

14. Product Tailoring submits the JMBL request to Warrior Pull for
    product retrieval.

15. Warrior Pull returns a response containing reference to product to
    Product Tailoring.

16. Product Tailoring alerts distribution that the product is available.

17. Product Tailoring logs the product build and dissemination
    notification actions via the Enterprise Notification.

18. This use case ends when a statistics message is sent to
    Infrastructure.

##### Alternate Flow Steps

> None.

##### Special Requirements

None.

#### Disseminate METOC Product

This Use Case flow describes the activities which are performed to
disseminate a METOC Product following receipt of a product ready
message. The product ready message can result from update of a catalog
item or expiration of a timer.

![](media/image8.wmf){width="5.990972222222222in" height="5.5125in"}

##### Actors

1.  Distribution

```{=html}
<!-- -->
```
1.  Subscription Services

2.  Data Access Layer

3.  Database

4.  Extended Dissemination Capability (EDC)

5.  Enterprise Notification

6.  User (endpoint)

7.  Infrastructure

##### Preconditions

1.  Product Ready Message is delivered to Distribution.

```{=html}
<!-- -->
```
1.  Product is available

2.  Product has active subscriptions to active endpoints.

##### Post Conditions

1.  The product is delivered as specified in the subscriptions.

2.  Dissemination Statistics are recorded.

3.  The EDC log contains an entry detailing the successful dissemination
    of the product to the specified users (endpoints).

4.  Response status for each subscription is sent to Subscription
    Services to update subscriptions and endpoints.

##### Basic Flow Steps

1.  This use case begins when Subscription Services receives a Product
    Ready message from Distribution.

2.  Subscription Services requests subscription data from the Database
    via the Data Access Layer.

3.  The Database returns active subscription data via the Data Access
    Layer.

4.  Subscription Services expands the destination filename based on
    product dependent embedded tokens.

5.  Subscription Services builds a Dissemination Control Document (DCD)
    containing dissemination directions for all endpoints which are to
    receive the current product.

6.  Subscription Services delivers the DCD to the Expanded Dissemination
    Capability for processing.

7.  The Expanded Dissemination Capability extracts the dissemination
    information for each endpoint.

8.  The Expanded Dissemination Capability creates appropriate standard
    or pseudo Long ASCII Headers if specified for the endpoint in the
    DCD.

9.  The Expanded Dissemination Capability applies compression to the
    source file if requested in the DCD.

10. The Expanded Dissemination Capability disseminates the data
    according to the DCD directives for each dissemination request.
    **\[A10\]**

11. The Expanded Dissemination Capability posts a log entry for each
    endpoint specified by the DCD.

12. The Expanded Dissemination Capability returns the dissemination
    status to Subscription Services.

13. The Expanded Dissemination Capability sends statistics for each
    dissemination to Infrastructure.

14. This use case ends when Subscription Services updates subscription
    status, based on the dissemination responses.

##### Alternate Flow Steps

###### Dissemination request failed.

1.  This alternate flow begins at step 100 when the configured retry
    attempts or retry period for a specific endpoint have been exceeded
    for a particular dissemination request.

2.  The Expanded Dissemination Capability posts a log entry detailing
    the endpoint that is failing and the conditions that caused the
    failure message to be sent.

3.  The EDC posts a response document to Subscription Services
    specifying that the dissemination request to the endpoint has
    exceeded the retry attempts or retry period limit.

4.  This alternate flow ends and flow returns to step 100 of the basic
    flow until all dissemination requests have been processed.

##### Special Requirements

> None.

#### Startup and Recovery of Expanded Dissemination Capability.

This use case describes what the Expanded Dissemination Capability
(EDC), an extension component of the Consolidated Dissemination
Component (CDC), does when the system is started. The EDC will evaluate
its internal queues and re-queue any dissemination requests that were
in-progress when the EDC stopped. The EDC will log what dissemination
requests were requeued.

![](media/image9.wmf){width="4.520833333333333in"
height="3.497916666666667in"}

##### Actors

1.  Expanded Dissemination Capability (EDC)

##### Preconditions

1.  EDC internal queues available.

2.  Dissemination Request Queue is available

3.  Dissemination Response Queue is available

##### Post Conditions

1.  The EDC successfully starts and any dissemination requests that
    where not completed when the EDC last stopped are re-queued for
    dissemination.

##### Basic Flow Steps

10 This use case begins when the EDC is started from a stopped state.

20 A log entry will be generated detailing that the EDC is starting.

30 The EDC will evaluate its internal queues prior to making any
connections or accepting new DCD requests and requeue for processing any
dissemination requests that did not complete when the EDC was last
running.

40 A log entry will be generated detailing each dissemination request
that is requeued.

50 The EDC will then attempt to connect to the DCD request queue.

60 A log entry will be generated detailing that the EDC is now accepting
new DCD requests.

70 This use case ends when the EDC is running, has requeued and is
processing all pending requests and is accepting new DCD requests.

##### Alternate Flow Steps

###### EDC cannot evaluate its internal queues.

A10 This alternate flow begins at step 30 when the EDC attempts to
evaluate its internal queues.

A20 A log entry will be generated detailing that the EDC could not
evaluate its internal queues and the reason the queues could not be
evaluated.

A30 This alternate flow ends when the EDC has successfully logged the
failure and flow is returned to step 30.

###### EDC cannot connect to DCD request queue.

B10 This alternate flow begins at step 50 when the EDC cannot establish
a connection with the DCD request queue.

B20 The EDC will generate a log entry detailing the failure to connect
and the reason that the connection failed.

B30 This alternate flow ends when the EDC has successfully logged the
failure and flow is returned to step 50.

##### Special Requirements

None.

## CDC GUI

### Basic Description

This thread of the JNIA CDC Use Case documents how the CDC GUI is used
to manage user and product data, along with how to define child and
parent products, edit product definitions, define and edit JMBL
products, delete products, as well as the MOC Setup, and management of
subscription products and endpoints.

![](media/image10.wmf)

### Manage User and Product Data

#### Manage User Data

![](media/image11.wmf){width="4.259722222222222in"
height="0.6569444444444444in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  CDC GUI

2.  Data Access Layer

3.  Database

4.  Enterprise Notification

##### Preconditions

1.  The CDC GUI is running.

2.  User has logged into the AF Portal, selected the WDAC application,
    and navigated to the CDC GUI.

3.  The Database is available.

##### Post Conditions

1.  The user data is defined and stored in the database.

2.  Status is logged.

##### Basic Flow Steps

1.  This use case begins when the privileged user accesses the CDC GUI.

2.  The user logs into the AF Portal and navigates to the CDC GUI link.

3.  The user chooses to manage user data.

4.  The user enters/modifies/deletes User Data and submits update
    request.

5.  The user data is stored/updated/deleted in JMCAT.

6.  Use case ends.

##### Alternate Flow Steps

None.

##### Special Requirements

None.

#### Manage Region Definitions

This use case flow describes a utility to define named geographical
regions and their extents.

![](media/image12.wmf){width="5.995833333333334in"
height="3.604861111111111in"}

##### Actors

1.  User

2.  CDC GUI

3.  Subscription Services

4.  Data Access Layer

5.  Database

6.  Enterprise Notification

##### Preconditions

1.  The User has logged in through the AF Portal and has the
    Administrator Role.

##### Post Conditions

1.  The named region is stored in the AFWWS database.

2.  The sample map is stored in the AFWWS database.

##### Basic Flow Steps

1.  This use case begins when the privileged user starts the CDC GUI and
    enters the name of a region. **\[A10\] \[B10\]**

2.  The User enters the minimum and maximum latitude parameters for the
    region.

3.  The User enters the minimum and maximum longitude parameters for the
    region.

4.  The User submits the region definition to the CDC GUI.

5.  The CDC GUI sends a store region definition request to the
    Subscription Services.

6.  The Subscription Services sends a store region definition request to
    the Data Access Layer.

7.  The Data Access Layer sends a store region definition request to the
    Database.

8.  The Database stores the named region and returns the store status to
    the Data Access Layer.

9.  The Data Access Layer sends the status of store message to
    Enterprise notification.

10. The Data Access Layer returns the store status to the Subscription
    Services.

11. The Subscription Services returns the store status to the CDC GUI.

12. This use case ends when the CDC GUI displays the status of the
    request to the User.

##### Alternate Flow Steps

###### User Edits an Existing Region

1.  This alternate flow begins at basic flow step 10 when the user
    selects to edit the entered region.

2.  The CDC GUI sends a region definition request to the Data Access
    Layer.

3.  The Data Access Layer sends a region definition request to the
    Database.

4.  The Database returns the region definitions to the Data Access
    Layer.

5.  The Data Access Layer returns the region definitions to the CDC GUI.

6.  The CDC GUI displays the region definitions for editing.

7.  This alternate flow returns to basic flow step 20.

###### User Deletes an Existing Region

1.  This alternate flow begins at basic flow step 10 when the user
    selects to delete the entered region.

2.  The CDC GUI sends a delete request to the Data Access Layer.

3.  The Data Access Layer sends a delete request to the Database.

4.  The Database deletes the named region.

5.  The Database returns the delete status to the Data Access Layer.

6.  The Data Access Layer returns the delete status to the CDC GUI.

7.  This alternate flow returns to basic flow step 120.

##### Special Requirements

1.  The names of the regions shall be unique.

2.  The regions shall be based on the WGS84 projection.

3.  The regions shall be defined by lower left and upper right latitude
    and longitude coordinates.

4.  The latitude shall range from -90 to 90 degrees.

5.  The longitude shall range from 0 to -180 degrees for the western
    hemisphere.

6.  The longitude shall range from 0 to 180 degrees for the eastern
    hemisphere.

#### Define Child Products - GUI

This Use Case flow describes the events that take place while defining a
child product from the CDC GUI and storing that definition into the
Database.

![](media/image13.wmf){width="6.814583333333333in"
height="3.3986111111111112in"}

##### Actors

1.  User

2.  CDC GUI

3.  Subscription Services

4.  Data Access Layer

5.  Database

6.  Enterprise Notification

##### Preconditions

1.  The CDC GUI is available via the AF Portal.

2.  Parent products are available within the Database.

##### Post Conditions

1.  Child product information is successfully defined in the Database.

##### Basic Flow Steps

1.  This use case begins when the User selects the menu item to define a
    child product in the CDC GUI.

```{=html}
<!-- -->
```
19. The CDC GUI requests the available parent products from the
    Subscription Services.

20. The Subscription Services requests the available parent products
    from the Data Access Layer.

21. The Data Access Layer requests the available parent products from
    the Database.

22. The Database returns the available parent products to the Data
    Access Layer.

23. The Data Access Layer returns the available parent products to the
    Subscription Services.

24. The Subscription Services returns the available parent products to
    the CDC GUI.

25. The CDC GUI displays the available parent products list and product
    specific parameters necessary for defining a tailored child product.

26. The User selects a parent product upon which to base a child
    product, enters criteria to tailor the parent product, and submits
    the child product definition to the CDC GUI.

27. The CDC GUI submits the child product definition to the Subscription
    Services.

28. The Subscription Services submits the child product definition to
    the Data Access Layer.

29. The Data Access Layer sends the new child product definition to the
    Database to be stored.

30. The Database returns the status of the product definition store to
    the Data Access Layer.

31. The Data Access Layer sends the status of the product definition
    store to Enterprise Notification.

32. The Data Access Layer returns the status of the product definition
    store to the Subscription Services.

33. The Subscription Services sends the status of the product definition
    store to CDC GUI.

34. This use case ends when the CDC GUI displays the status of the child
    product definition to the User.

##### Alternate Flow Steps

> None.

##### Special Requirements

> S10 If the action will take more than 7 seconds to complete, display
> an indicator.

#### Define Parent Products - GUI

This Use Case flow describes the events that take place while defining a
parent product from the CDC GUI and storing it into the Database.

![](media/image14.wmf){width="6.496527777777778in"
height="3.370138888888889in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  CDC GUI

```{=html}
<!-- -->
```
1.  Subscription Services

2.  Data Access Layer

3.  Database

4.  Enterprise Notification

##### Preconditions

1.  The CDC GUI is available via the AF Portal.

```{=html}
<!-- -->
```
1.  The User has privileges to define parent products.

##### Post Conditions

1.  Parent product is successfully defined in the Database.

##### Basic Flow Steps

1.  This use case begins when the User selects the menu item to define a
    parent product in the CDC GUI, specifying the data type of parent
    product being defined.

```{=html}
<!-- -->
```
35. The CDC GUI displays a data entry form tailored to the metadata
    necessary for defining a parent product of the data type selected.

36. The User enters the parent product definition into the CDC GUI.

37. The CDC GUI submits the parent product definition to the
    Subscription Services.

38. The Subscription Services submits the parent product definition to
    the Data Access Layer.

39. The Data Access Layer sends the new parent product definition to the
    Database to be stored.

40. The Database returns the status of the product definition store to
    the Data Access Layer.

41. The Data Access Layer sends the status of the product definition
    store to Enterprise Notification.

42. The Data Access Layer returns the status of the product definition
    store to the Subscription Services.

43. The Subscription Services sends the status of the parent product
    store to the CDC GUI.

44. This use case ends when the CDC GUI displays the status of the
    parent product definition to the User.

##### Alternate Flow Steps

> None.

##### Special Requirements

S10 If the action will take more than 7 seconds to complete, display an
indicator.

#### Edit Products

This Use Case flow describes the events that take place to edit and
store a product definition via the CDC GUI.

![](media/image15.png){width="6.498611111111111in"
height="4.379166666666666in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  CDC GUI

```{=html}
<!-- -->
```
1.  Subscription Services

2.  Data Access Layer

3.  Database

4.  Enterprise Notification

##### Preconditions

1.  The CDC GUI is available via the AF Portal.

```{=html}
<!-- -->
```
1.  The product definition to be edited is available within the
    Database.

2.  The User has sufficient privileges to edit the product.

##### Post Conditions

1.  The product definition is successfully updated in the Database.

##### Basic Flow Steps

1.  This use case begins when the User requests to edit a JMBL product
    definition.

```{=html}
<!-- -->
```
45. CDC GUI requests product definition information from the
    Subscription Services.

46. Subscription Services requests product definition information from
    the Data Access Layer.

47. Data Access Layer requests the product definition information from
    Database.

48. Database provides the product definition information to Data Access
    Layer.

49. Data Access Layer provides the product definition information to
    Subscription Services.

50. Subscription Services provides the product definition information to
    the CDC GUI.

51. CDC GUI displays product definition to the User.

52. User selects a product to edit.

53. CDC GUI displays the selected product.

54. User edits and submits product definition using CDC GUI.

55. CDC GUI requests product update to Subscription Services.

56. Subscription Services requests product update to Data Access Layer.

57. Data Access Layer sends edited product to the Database to be
    updated.

58. Database sends update status to Data Access Layer.

59. Data Access Layer sends update status to Subscription Services.

60. Subscription Services sends update status to CDC GUI.

61. CDC GUI logs the status message to Enterprise Notification.

62. CDC GUI displays confirmation that the product has been updated.

63. The use case ends.

##### Alternate Flow Steps

None.

##### Special Requirements

S10 If an action will take the CDC GUI more than 7 seconds to complete,
display an indicator.

#### Define JMBL Products

This Use Case flow describes the events for defining new JMBL products
via the CDC GUI. The use case depicts the Inventory Method and the Text
Entry Method for defining JMBL Products. In the Inventory Method, the
User constructs a JMBL product definition by the guidance of stored
metadata (inventory parameters) and elements of the GUI (such as
pull-down lists offering valid values for a particular parameter). In
the Text Entry Method, the User directly enters a complete JMBL query
into a text-submission element of the GUI.

![](media/image16.wmf){width="6.496527777777778in"
height="4.913888888888889in"}

#####  Actors

1.  User

```{=html}
<!-- -->
```
1.  CDC GUI

```{=html}
<!-- -->
```
1.  Data Access Layer

2.  Database

3.  Warrior Pull

4.  Enterprise Notification

##### Preconditions

1.  The CDC GUI is available via the AF Port.

##### Post Conditions

1.  JMBL product is successfully defined in the Database.

##### Basic Flow Steps

1.  This use case begins when the User navigates to the section of the
    CDC GUI where they can define a new JMBL product.

2.  The User selects the data type for the product being defined and
    chooses Inventory as the method for defining the JMBL product.
    **\[A10\]**.

3.  The CDC GUI accesses the Data Access Layer to retrieve inventory
    parameters appropriate to the data type selected by the User.

4.  The Data Access Layer retrieves inventory parameters from the
    Database.

5.  The Database returns the inventory parameters to the Data Access
    Layer.

6.  The Data Access Layer returns the inventory parameters to the CDC
    GUI.

7.  The CDC GUI displays the inventory parameters to the User.

8.  The User selects and submits all criteria necessary to define the
    JMBL product.

9.  The CDC GUI displays the resulting JMBL Request to the User.

10. The User validates the JMBL Request to test retrieval of the data.

11. The CDC GUI submits the JMBL/SOAP METOC Query to Warrior Pull.

12. Warrior Pull returns to CDC GUI a JMBL/SOAP Response containing a
    success or failure status of the request and, if successful, a
    reference to the product. **\[B10\] \[C10\]**

13. The CDC GUI displays to User the request status and, if the query
    was successful, the reference to the product.

14. The User submits a request to store the product definition to the
    CDC GUI.

15. The CDC GUI requests the Data Access Layer to define the JMBL
    product using the definition submitted by the User.

16. The Data Access Layer sends the new JMBL product definition to the
    Database to be stored, defining the product.

17. The Database returns the status of the product definition to the
    Data Access Layer.

18. The Data Access Layer sends the status of the JMBL product storage
    to Enterprise Notification.

19. The Data Access Layer sends the status of the JMBL product storage
    to the CDC GUI.

20. This use case ends when the CDC GUI displays the status of the JMBL
    product definition to the User.

##### Alternate Flow Steps

###### Text Entry of JMBL Request for Product

1.  This alternate flow begins after basic flow step 20 when the User
    selects Text Entry as the method for adding a JMBL product,
    including the data type for the product being defined.

2.  The User enters a JMBL request.

3.  This alternate flow returns to Basic Flow Step 100.

###### JMBL Request Fails Validation

1.  This alternate flow begins when the JMBL request fails validation in
    basic flow step 120.

2.  The CDC GUI displays a message indicating why the validation failed.

3.  Alternate flow returns to step 70 (or, in the case of Text Entry
    method, it returns to alternate flow step A20) and displays the
    request entry screen, populated with previously entered data.

###### JMBL Request Returns No Data

1.  This alternate flow begins when the validation succeeds but returns
    no data in step 120 of the basic flow.

2.  The CDC GUI displays a message indicating that the JMBL query is
    valid but the requested data is not currently available in the
    Database.

3.  Alternate flow returns to step 70 (or, in the case of Text Entry
    method, it returns to alternate flow step A20) and displays the
    request entry screen, populated with previously entered data.

##### Special Requirements

1.  The User will have the option to validate the JMBL request, but
    validation will not be mandatory.

2.  If the User chooses to validate the JMBL request and the validation
    indicates the product is available in the Database, the CDC GUI will
    also offer the User an opportunity to download the product.

3.  The User will have the option to subscribe to the product in this
    GUI, but subscription will not be mandatory.

4.  If the action will take more than 7 seconds to complete, display an
    indicator.

#### Edit JMBL Products

This use case flow begins when a request is received to edit JMBL
products. When the edit request is received, a query to the database
will retrieve the product definition data. The product definition is
edited and the database is updated.

![](media/image17.png){width="5.999305555555556in"
height="3.8895833333333334in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  CDC GUI

```{=html}
<!-- -->
```
1.  Subscription Services

2.  Data Access Layer

3.  Database

4.  Enterprise Notification

##### Preconditions

1.  All Actors are available.

```{=html}
<!-- -->
```
1.  JMBL Product available for editing.

##### Post Conditions

1.  The User has successfully edited a JMBL product definition.

```{=html}
<!-- -->
```
1.  Action logged in Enterprise Notification.

##### Basic Flow Steps

1.  This use case begins when the User requests to edit a JMBL product
    definition.

```{=html}
<!-- -->
```
64. CDC GUI requests product definition information from the
    Subscription Services.

65. Subscription Services requests product definition information from
    the Data Access Layer.

66. Data Access Layer requests the product definition information from
    Database.

67. Database returns the product definition information to Data Access
    Layer.

68. Data Access Layer returns the product definition information to
    Subscription Services.

69. Subscription Services returns the product definition information to
    the CDC GUI.

70. CDC GUI displays product definition to the User.

71. User edits product definition using CDC GUI.

72. CDC GUI requests product update to Subscription Services.

73. Subscription Services requests product update to Data Access Layer.

74. Data Access Layer sends edited product to the Database to be
    updated.

75. Database sends update status to Data Access Layer.

76. Data Access Layer sends update status to Subscription Services.

77. Subscription Services sends update status to CDC GUI.

78. CDC GUI logs the status message to Enterprise Notification.

79. CDC GUI displays product update confirmation.

80. The use case ends.

##### Alternate Flow Steps

None.

##### Special Requirements

None.

#### Delete Products

This Use Case flow describes the events that take place when the User
decides to delete one or more products via the CDC GUI.

![](media/image18.wmf){width="6.486111111111111in"
height="4.423611111111111in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  CDC GUI

2.  Data Access Layer

3.  Database

4.  Enterprise Notification

##### Preconditions

1.  The CDC GUI is available via the AF Portal.

2.  Products are available within the Database.

3.  The User has sufficient privileges to delete products.

##### Post Conditions

1.  One or more products have been successfully deleted from the
    Database.

##### Basic Flow Steps

1.  This use case begins when the User navigates to the CDC GUI and
    submits a request to view their product list.

```{=html}
<!-- -->
```
81. The CDC GUI sends a request to retrieve the product list to the Data
    Access Layer.

82. The Data Access Layer submits a request to retrieve the product list
    from the Database.

83. The Database returns the product list to the Data Access Layer.

84. The Data Access Layer returns the product list to the CDC GUI.

85. The CDC GUI displays the product list to the User.

86. The User selects one or more products from the product list to
    delete.

87. The User submits the product deletion request to the CDC GUI.

88. The CDC GUI sends the product deletion request to the Data Access
    Layer.

89. The Data Access Layer sends the product deletion request to the
    Database.

90. The Database returns the product deletion status to the Data Access
    Layer.

91. The Data Access Layer sends the product deletion status to
    Enterprise Notification.

92. The Data Access Layer sends the product deletion status to the CDC
    GUI.

93. This use case ends when the CDC GUI displays the product deletion
    status to the User.

##### Alternate Flow Steps

None.

##### Special Requirements

1.  The CDC GUI will allow the user to delete more than one product at a
    time.

2.  If the action will take more than 7 seconds to complete, display an
    indicator.

#### MOC Setup

![](media/image19.wmf){width="4.238888888888889in"
height="0.6569444444444444in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  CDC GUI

```{=html}
<!-- -->
```
1.  Database

2.  Data Access Layer

3.  Enterprise Notification

##### Preconditions

1.  The CDC GUI is running

2.  User has logged into the AF Portal, selected the WDAC application,
    and navigated to the CDC GUI

3.  The Database is available

4.  The MOC definitions are stored in the Database

##### Post Conditions

1.  The MOC definition is stored in the Database.

2.  Action logged in Enterprise Notification.

##### Basic Flow Steps

1.  This use case begins when a user accesses the CDC GUI.

```{=html}
<!-- -->
```
1.  The user logs into the AF Portal and navigates to the CDC GUI link.

```{=html}
<!-- -->
```
1.  The user chooses to define a Model of Consistency (MOC).

2.  A MOC setup GUI is displayed from which the user selects an Area of
    Responsibility (AOR) or subregion, with which the model of
    consistency is to be associated from a list of valid AOR selections
    or selecting a point on a map.

3.  The user selects a MOC to associate with the selected AOR from a
    list of valid models.

4.  The MOC specification is stored for future use.

5.  Use case end.

##### Alternate Flow Steps

None.

##### Special Requirements

None.

#### Manage Subscription Data

![](media/image20.wmf){width="4.259722222222222in"
height="0.6569444444444444in"}

##### Actors

1.  User

2.  CDC GUI

3.  Data Access Layer

4.  Database

5.  Enterprise Notification

##### Preconditions

1.  The CDC GUI is running.

2.  User has logged into the AF Portal, selected the WDAC application,
    and navigated to the CDC GUI.

3.  The Database is available.

4.  The product definition that the User wants to subscribe to is stored
    in the Database.

##### Post Conditions

1.  The subscription is defined and stored in the Database.

##### Basic Flow Steps

1.  This use case begins when the User accesses the CDC GUI.

```{=html}
<!-- -->
```
94. The user logs into the AF Portal and navigates to the CDC GUI link.

95. The user chooses to manage subscription data.

96. The user enters/modifies/deletes subscription data and submits
    update request.

97. The subscription data is stored/updated/deleted in JMCAT

98. Use case ends.

##### Alternate Flow Steps

1.  This alternate flow step begins at step 40, when the User selects an
    existing child product, rather than an existing parent product.

2.  The user modifies the area and/or the parameters of the existing
    child product.

3.  This alternate flow ends, returning to Basic flow step 60.

##### Special Requirements

> None.

#### Load Catalog Products

This Use Case flow describes the events that take place while storing
one or more parent products into the Database.

![](media/image21.wmf){width="5.102777777777778in"
height="2.636111111111111in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  Database

##### Preconditions

1.  User has sufficient privileges to run product loader.

##### Post Conditions

1.  Products are stored into the Database.

##### Basic Flow Steps

1.  This use case begins when the user starts the product loader.

2.  The Database stores the products.

3.  This use case ends when the products are stored in the Database and
    status is returned to the User.

##### Alternate Flow Steps

None.

##### Special Requirements

None.

#### Add Catalog Subscription

This Use Case flow describes the actions when the user selects "Add
Catalog Subscription" from the CDC GUI menu. The use case flow ends when
the user is notified of the status of the subscription attempt.

![](media/image22.png){width="6.156944444444444in"
height="6.728472222222222in"}

##### Actors

1.  User

2.  CDC GUI

3.  Subscription Services

4.  Data Access Layer

5.  Database

6.  Enterprise Notification

##### Preconditions

1.  The CDC GUI is available via the AF Portal.

2.  Catalog Products are available in Database.

3.  An endpoint is available in the Database for the subscription.

##### Post Conditions

1.  The user has successfully added a subscription to a product via the
    CDC GUI.

##### Basic Flow Steps

1.  This use case begins when the User navigates to the section of the
    CDC GUI for adding a new subscription.

```{=html}
<!-- -->
```
99. The CDC GUI requests a list of products from the Subscription
    Services.

100. The Subscription Services request a list of products from the Data
     Access Layer.

101. The Data Access Layer retrieves a list of products from the
     Database.

102. The Database returns the list of products to the Data Access Layer.

103. The Data Access Layer returns the product list to Subscription
     Services.

104. The Subscription Services returns the product list to the CDC GUI.

105. The CDC GUI requests a list of endpoints from Subscription
     Services.

106. The Subscription Services requests a list of endpoints from the
     Data Access Layer.

107. The Data Access Layer retrieves a list of endpoints from the
     Database.

108. The Database returns the list of endpoints to the Data Access
     Layer.

109. The Data Access Layer returns the endpoints list to Subscription
     Services.

110. The Subscription Services returns the endpoints to the CDC GUI.

111. The CDC GUI displays the list of products as product taxonomy.

112. The CDC GUI displays the list of endpoints.

113. The user submits a subscription name, an endpoint from the endpoint
     list, one or more products from the taxonomy, subscription start
     and end dates, and subscription status to define the new
     subscription to the CDC GUI.

114. The CDC GUI requests Subscription Services to store the
     subscription definition.

115. The Subscription Services request the Data Access Layer to store
     the subscription definition.

116. The Data Access Layer requests the Database to store the
     subscription definition.

117. The Database returns the status of the subscription store to Data
     Access Layer.

118. The Data Access Layer returns the status of the subscription store
     to Subscription Services.

119. The Subscription Services returns the status of the subscription
     store to the CDC GUI.

120. The CDC GUI sends a message to Enterprise Notification indicating
     that a subscription was created.

121. The CDC GUI displays the status of the subscription creation to the
     user.

122. This use case ends.

##### Alternate Flow Steps

> None.

##### Special Requirements

> None.

#### Edit Catalog Subscription

This use case flow describes the activities required to edit a
subscription to a product via the CDC GUI. The use case begins when the
user navigates to the edit subscription page of the CDC GUI and ends
when the CDC GUI receives and displays notification of the status of the
subscription update. There are no data specific activities in the Edit
Catalog Subscription process.

![](media/image23.wmf){width="5.986111111111111in"
height="4.934027777777778in"}

##### Actors

1.  User

2.  CDC GUI

3.  Data Access Layer

4.  Database

5.  Enterprise Notification

##### Preconditions

> 1\. The CDC GUI is available.
>
> 2\. The subscription data is available in the Database.

##### Post Conditions

1.  The subscription data is updated in the JMCAT database.

2.  Successful status is displayed by the CDC GUI.

##### Basic Flow Steps

1.  This use case begins when the user navigates to the section of the
    CDC GUI for editing existing subscriptions to products.

```{=html}
<!-- -->
```
123. The CDC GUI retrieves subscription information from the Database
     via the Data Access Layer.

124. The CDC GUI allows the user to select a subscription and edit the
     subscription parameters.

125. The CDC GUI submits a subscription update request to the Data
     Access Layer.

126. The Data Access Layer requests an update of the subscription in the
     Database.

127. The Database updates the subscription data.

128. The Database returns the update status to the CDC GUI via the Data
     Access Layer.

129. The CDC GUI sends a message to Enterprise Notification indicating
     that the subscription was updated.

130. This use case ends when the CDC GUI displays the update status to
     the User

##### Alternate Flow Steps

> None.

##### Special Requirements

> None.

#### Delete Subscription to a Product

This use case flow describes the actions the user takes to delete a
subscription to a product via the CDC GUI. The use case flow begins when
the user activates the CDC GUI and navigates to the delete subscription
screen. This use case flow ends when Data Access Layer sends a message
to the CDC GUI indicating that the subscription was successfully
deleted.

![](media/image24.wmf){width="6.495833333333334in"
height="3.001388888888889in"}

##### Actors

1.  User

2.  CDC GUI

3.  Data Access Layer

4.  Database

5.  Enterprise Notification

##### Preconditions

1.  The CDC GUI is available via the AF Portal.

2.  The subscription data is available in the Database.

##### Post Conditions

1.  The user has successfully deleted a subscription to a product via
    the CDC GUI.

##### Basic Flow Steps

1.  This use case begins when the user navigates to the section of the
    CDC GUI for viewing a subscription to a product.

2.  The CDC GUI displays the list of subscription(s) for the user.

3.  The user selects one or more subscription(s) to delete by
    subscription name.

4.  The Data Access Layer removes the subscription(s) from the Database.

5.  The Data Access Layer sends a message to Enterprise Notification
    indicating that subscription(s) was deleted.

6.  This use case ends when the Data Access Layers sends a message to
    the CDC GUI indicating that the subscription(s) was successfully
    deleted.

##### Alternate Flow Steps

None.

##### Special Requirements

> None.

#### Enter Legacy Filename Tokens

This use case describes the process for entering a Remote Filename
template, with optional tokens, for the subscribed product.

![](media/image25.png){width="5.330555555555556in"
height="2.201388888888889in"}

##### Actors

1.  User

2.  CDC GUI

##### Preconditions

1.  The User is logged into the CDC GUI and is ready to enter a Remote
    Filename template for a subscription.

##### Post Conditions

1.  The Remote Filename template is saved with a subscription.

##### Basic Flow Steps

1.  This use case begins at Basic Flow 2.1.1.4 step 340 in the parent
    use case "ST-JNIA-02 JNIA CDC" when a user is ready to enter a
    Remote Filename for a subscription.

2.  The user enters the Remote Name ( or none, if desired). The Remote
    Name may include tokens and flags as defined in "Supported Filename
    Tokens.doc" to support legacy product filenames.

3.  The user submits the subscription.

4.  The CDC GUI validates the Remote Filename template.

5.  The use case ends when the CDC GUI saves the subscription with the
    Remote Filename template.

##### Alternate Flow Steps

###### The Remote Filename contains one or more invalid or malformed tokens.

1.  This alternate flow begins when the CDC GUI determines that the
    Remote Filename template contains one or more invalid or malformed
    tokens.

```{=html}
<!-- -->
```
1.  The user is notified by screen messages that tokens are invalid or
    malformed.

2.  Alternate flow ends when the user is returned to step 20.

##### Special Requirements

None.

#### Add Endpoint 

This use case flow details the steps needed to add an endpoint to the
database. An endpoint is attached to a route and denotes the final
destination for any product dissemination.

A server is an extension of an endpoint and therefore can also be the
final destination for any product dissemination. A server has the added
responsibility of forwarding the product along the route until it is
delivered to its final destination. A route will consist of a series of
servers linked together in a sequential order.

The User will add the endpoints through use of the CDC GUI. The User
begins by setting the attributes of the endpoint specifying whether the
endpoint is a server. The User then optionally validates the endpoint.
The User submits the added endpoint to the database. The CDC GUI
displays the status of the database operation.

An FTP or File System Endpoint consists of the Network Nodename (or IP
address) and the Directory. Given these definitions of an Endpoint, a
collision can only occur if the user-provided values for these two items
are the same as another Endpoint in the database. In this case the
endpoint creation will fail and the user will be informed.

This use case begins when the User chooses to add an endpoint to the
database. It ends when the User examines the status of the database
action displayed on the CDC GUI.

[]{.mark}

![](media/image26.wmf){width="6.503472222222222in"
height="3.959722222222222in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  CDC GUI

2.  Data Access Layer

3.  Database

4.  Enterprise Notification

##### Preconditions

1.  The User has access to the CDC GUI with the administrator role.

2.  The endpoint does not exist in the database.

##### Post Conditions

1.  The endpoint is added to the database.

##### Basic Flow Steps

1.  This use case begins when the User chooses to add an endpoint.

```{=html}
<!-- -->
```
131. The User fills in the endpoint attributes.

132. The User optionally validates any directly connected endpoint.

133. The User submits the configured endpoint.

134. The Data Access Layer logs the action with the Enterprise
     Notification.

135. This Use Case ends when the User examines the status displayed on
     the CDC GUI.

##### Alternate Flow Steps

None.

##### Special Requirements

None.

#### Modify Endpoint

This Use Case flow details the steps needed to modify an endpoint in the
database. An endpoint is attached to a route and denotes the final
destination for any product dissemination.

A server is an extension of an endpoint and therefore can also be the
final destination for any product dissemination. A server has the added
responsibility of forwarding the product along the route until it is
delivered to its final destination. A route will consist of a series of
servers linked together in a sequential order.

The User will modify the endpoints through use of the CDC GUI. The User
begins by selecting an endpoint from a list of endpoints. The User
modifies the attributes of the endpoint. The User then optionally
validates the endpoint. The User submits the modified endpoint to the
database. The Data Access Layer sends an Endpoint Modification message
to the Extended Dissemination Capability. The Data Access Layer logs the
Endpoint modification with the Enterprise Notification. The CDC GUI
displays the status of the database operation.

The Data Access Layer will not allow a server to transition from active
to inactive/pending if it is participating in any routing. The User will
have to remove the server from any Route before marking it inactive.

This use case begins when the User chooses to modify an endpoint in the
database. It ends when the User examines the status of the database
action displayed on the CDC GUI.

![](media/image27.wmf){width="6.488888888888889in"
height="4.082638888888889in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  CDC GUI

2.  Data Access Layer

3.  Database

4.  Extended Dissemination Capability

5.  Enterprise Notification

##### Preconditions

1.  The User has access to the CDC GUI with the proper role.

```{=html}
<!-- -->
```
1.  The endpoint already exists in the database.

##### Post Conditions

1.  The endpoint is modified in the database.

##### Basic Flow Steps

1.  This use case begins when the User chooses to modify an endpoint.

```{=html}
<!-- -->
```
136. The CDC GUI supplies the User with a list of endpoints.

137. The User selects the endpoint from a list of endpoints.

138. The User modifies the attributes of the endpoint.

139. The User optionally validates the modified endpoint.

140. The User submits the modified endpoint.

141. The Data Access Layer sends an Endpoint modification message to
     Extended Dissemination Capability.

142. The Data Access Layer logs the action with the Enterprise
     Notification.

143. This Use Case ends when the User examines the status displayed on
     the CDC GUI.

##### Alternate Flow Steps

None.

##### Special Requirements

> S10 The Data Access Layer will not allow a server to transition from
> active to inactive/pending if it is participating in any routing.

#### Delete Endpoint

This Use Case flow details the steps needed to delete an endpoint in the
database. An endpoint is attached to a route and denotes the final
destination for any product dissemination.

A server is an extension of an endpoint and therefore can also be the
final destination for any product dissemination. A server has the added
responsibility of forwarding the product along the route until it is
delivered to its final destination. A route will consist of a series of
servers linked together in a sequential order.

The User will delete the endpoint through use of the CDC GUI. The CDC
GUI provides the User with a list of endpoints. It will set any server
to read only and thereby prevent its selection. The User selects an
endpoint from this list. The User submits the deletion of the endpoint
to the database. The Data Access Layer marks all associated
subscriptions Inactive. The Data Access Layer sends an Endpoint Deletion
message to the Extended Dissemination Capability. The Data Access Layer
Logs the Endpoint deletion with the Enterprise Notification. The CDC GUI
displays the status of the database operation.

The CDC GUI will not allow the user to select a server. Only Endpoints
not functioning as a server can be deleted.

This use case begins when the User chooses to delete an endpoint in the
database. It ends when the User examines the status of the database
action displayed on the CDC GUI.

![](media/image28.wmf){width="6.059722222222222in"
height="3.8333333333333335in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  CDC GUI.

2.  Data Access Layer

3.  Database

4.  Extended Dissemination Capability

5.  Enterprise Notification

##### Preconditions

1.  The User has access to the CDC GUI with the administrator role.

```{=html}
<!-- -->
```
1.  The endpoint already exists in the database.

##### Post Conditions

1.  The endpoint is deleted from the database.

##### Basic Flow Steps

1.  This use case begins when the User chooses to delete an endpoint.

```{=html}
<!-- -->
```
144. The CDC GUI provides a list of endpoints.

145. The CDC GUI sets any server to read only.

146. The User selects the endpoint from the list of endpoints.

147. The CDC GUI provides a listing of all subscriptions and their state
     (Active or Inactive) associated with the end point.

148. The CDC GUI provides a warning message concerning the state
     transition of any associated subscription.

149. The User submits the endpoint deletion to the CDC GUI.

150. The Data Access Layer sets the associated Subscriptions to pending.

151. The Data Access Layer deletes the Endpoint.

152. The Data Access Layer sends an Endpoint deletion message to
     Extended Dissemination Capability.

153. The Data Access Layer logs the Subscription update with the
     Enterprise Notification.

154. The Data Access Layer logs the Endpoint deletion with the
     Enterprise Notification.

155. This Use Case ends when the User examines the status displayed on
     the CDC GUI.

##### Alternate Flow Steps

None.

##### Special Requirements

None.

## Command Line Utilities

### Define Gridded INFO or READY Products

This Use Case flow describes the events that take place while defining
and loading a Gridded INFO or READY product into the Database.

![](media/image29.wmf){width="5.502777777777778in" height="2.5625in"}

#### Actors

1.  User

2.  Database

#### Preconditions

1.  User has sufficient privileges execute product loader.

2.  Data has been previously loaded (one time only) into the
    griddedTheaterNestTable.

#### Post Conditions

> 1\. Gridded INFO or READY product is loaded into the Database.

#### Basic Flow Steps

1.  This use case begins when the user starts the gridded INFO and READY
    product loader.

2.  User specifies the following command line parameters: database
    identifier (afwws, afwwstst, afwwsdev), model name (MM5, WRF, SCFM
    or DCF/DCF-5LYR), location name, data set name, cycle base time,
    starting forecast hour, ending forecast hour, hourly increment,
    theater number or 0, nest designator or ?. The theater number and
    nest are optional and ignored for SCFM model.

3.  The loader constructs the definitions based on user entries and
    contents of the AFWWS database.

4.  The loader submits the definitions to the AFWWS database.

5.  The Database stores the data.

6.  This use case ends when the Gridded INFO and READY product
    definitions are stored in the Database and status written to a log
    file.

#### Alternate Flow Steps

> None.

#### Special Requirements

1.  INFO and READY products shall have a unique product type.

2.  INFO and READY products shall not be displayed by the subscription
    GUI.

### Manage INFO or READY Product Subscription

This Use Case flow describes the actions that an administrator takes to
add a subscription to an INFO and/or READY product on behalf of a legacy
subscriber. This activity is supported only via a command line tool.

The INFO and READY files are used by selected legacy applications to
signal the completion of entire gridded model runs (MM5, WRF, SCFM, and
DCF only). Subscription to the INFO and READY products are supported by
a command line interface. A conscious decision was made to avoid GUI
access to these products. Use of this capability by knowledgeable
managers will prevent end user confusion over which product is
appropriate for their applications.

![](media/image30.wmf){width="5.772222222222222in"
height="2.2694444444444444in"}

#### Actors

1.  User

2.  Database

#### Preconditions

1.  User has sufficient privileges to run the Manage INFO or READY
    subscription tool.

2.  The INFO and READY product definitions exist in the Database.

3.  End Point for subscription must exist in the Database.

#### Post Conditions

> 1\. Gridded INFO or READY product subscription is loaded into or
> deleted from the Database according to the directive.

#### Basic Flow Steps

1.  This use case begins when the user starts the INFO and READY
    subscription tool.

2.  The INFO and READY subscription tool accepts a database identifier,
    the Product Name or "?", endpoint name, the owner of the endpoint
    (many use WDAC.ADMIN), destination filename and "ADD" or "DELETE"
    directive.

3.  The INFO and READY subscription tool assembles the subscription
    information and submits the subscription request to the Database.

4.  The Database adds or deletes the subscription data.

5.  This use case ends when the subscription to the Gridded INFO or
    READY product is stored into or deleted from the Database and status
    is returned to the User.

#### Alternate Flow Steps

##### A "?" is Entered for Product Name field

1.  This alternate flow begins at basic flow step 20 when the user
    enters a "?" for the Product Name.

2.  The subscription tool extracts a list of available INFO, PRE-INFO
    and READY products and writes the list to a file
    (INFO_ProductList.txt).

3.  This alternate flow ends when the user views the file and copies a
    product name to a buffer for use in a subsequent execution of the
    subscription tool.

#### Special Requirements

> None.

## Management GUI

### Basic Description

This thread of the JNIA CDC Use Case documents how the Management GUI is
used to manage organization and user data, routes, endpoints and
products.

![](media/image31.wmf)

### Manage User Data

![](media/image11.wmf){width="4.259722222222222in"
height="0.6569444444444444in"}

#### Actors

1.  User

```{=html}
<!-- -->
```
1.  CDC GUI

2.  Data Access Layer

3.  Database

4.  Enterprise Notification

#### Preconditions

1.  The CDC GUI is running.

```{=html}
<!-- -->
```
1.  User has logged into the AF Portal, selected the WDAC application,
    and navigated to the CDC GUI.

2.  The Database is available.

#### Post Conditions

1.  The user data is defined and stored in the database.

```{=html}
<!-- -->
```
1.  Status is logged.

#### Basic Flow Steps

1.  This use case begins when the privileged user accesses the CDC GUI.

```{=html}
<!-- -->
```
156. The user logs into the AF Portal and navigates to the CDC GUI link.

157. The user chooses to manage user data.

158. The user enters/modifies/deletes User Data and submits update
     request.

159. The user data is stored/updated/deleted in JMCAT.

160. Use case ends.

##### Alternate Flow Steps

None.

##### Special Requirements

None.

### Manage Routes

#### Add a Route

This Use Case flow details the steps needed to add a route to the
database. The route will consist of a series of servers linked together
in a sequential order. A route will be identified by a series of server
names.

The User is required to create the routes needed to support product
dissemination. Initially the routes from AFWED will be preloaded into
the database. Additional routes will be added through this use case.

The User will create the route through use of the Management GUI. The
User selects a server from a list of servers provided by the Management
GUI and adds it to the route. The User continues to select a server and
add it to the route in a sequential order until the route is
established. The User submits the route to the database. The Management
GUI displays the status of the database action.

The routes management page will not allow the User to select an inactive
server. Only active servers can be added to a route.

This use case begins when the User chooses to add a route to the
database. It ends when the User examines the status of the database
action displayed on the Management GUI.

![](media/image32.wmf){width="5.639583333333333in" height="4.8in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  Management GUI

2.  Data Access Layer

3.  Database

4.  Enterprise Notification

##### Preconditions

1.  The User has access to the Management GUI with the administrator
    role.

2.  The server information exists in the database.

##### Post Conditions

1.  The route is added in the database.

##### Basic Flow Steps

1.  This use case begins when the User chooses to add a route.

```{=html}
<!-- -->
```
161. The Management GUI provides a list of servers to the User.

162. The User selects the server from the list and adds it to the route.

163. The User returns to step 30 until all required servers are added to
     the route.

164. The User submits the configured route.

165. The Data Access Layer logs the action to the Enterprise
     Notification.

166. This Use Case ends when the User examines the status displayed on
     the Management GUI.

##### Alternate Flow Steps

> None.

##### Special Requirements

> S10 The routes management page will not allow the User to select an
> inactive server. Only active servers can be added to a route.

#### Edit a Route

This Use Case flow details the steps needed to edit the route. The route
will consist of a series of servers linked together in a sequential
order. A route will be identified by a series server names which
comprise the route.

The User will edit the route through use of the Management GUI. The
Management GUI provides a list of routes and servers to the User. The
User selects a route from the list and updates the contents of the
route. The User continues to add or deletes a server from the selected
route until the route is reestablished. The User submits the update to
the database. The Management GUI displays the status of the database
action.

The Management GUI will not allow the User to add an inactive server to
a route or delete an active server from a route. Only inactive servers
can be deleted from a route and only active servers can be added to a
Route.

This use case begins when the User chooses to modify an existing route.
It ends when the User examines the status of the database action
displayed on the Management GUI.

![](media/image33.wmf){width="5.000694444444444in"
height="4.502777777777778in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  Management GUI (Management GUI)

2.  Data Access Layer

3.  Database

4.  Extended Dissemination Capability

5.  Enterprise Notification

##### Preconditions

1.  The User has access to the management GUI with the administrator
    role.

```{=html}
<!-- -->
```
1.  The routing data is configured in the database.

##### Post Conditions

1.  The route is updated in the database.

##### Basic Flow Steps

1.  This use case begins when the User chooses to edit the route data.

```{=html}
<!-- -->
```
167. The Management GUI provides a list of routes to the User.

168. The Management GUI provides a list of servers to the User.

169. The User selects the route from a list of routes.

170. The User updates attributes of the route.

171. The User submits the reconfigured route.

172. The Data Access Layer sends a Route Modification Message to the
     EDC.

173. The Data Access Layer logs the action to the Enterprise
     Notification subsystem.

174. This Use Case ends when the User examines the status displayed on
     the Management GUI.

##### Alternate Flow Steps

> None.

##### Special Requirements

> S10 The Management GUI will not allow the User to add an inactive
> server to a route.
>
> S20 The Management GUI will not allow the User to delete an active
> server from a route..

#### Delete a Route

This Use Case flow details the steps needed to delete a route from the
database. The route will consist of a series of servers linked together
in a sequential order. A route will be identified by a series server
names which comprise the route.

The User will delete the route through use of the Management GUI. The
Management GUI will provide a list of routes. The User selects the
route. The User submits the route for deletion from the system. The
Management GUI displays the status of the database action.

Any endpoints attached to a deleted route are transitioned to a pending
state waiting on the User to assign routing. Endpoints in a pending
state cannot have products associated with them (i.e., subscription).

This use case begins when the User selects to delete an existing route.
It ends when the User examines the status of the database action
displayed on the Management GUI.

![](media/image34.wmf){width="5.885416666666667in" height="5.09375in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  Management GUI

2.  Data Access Layer

3.  Database

4.  Extended Dissemination Capability

5.  Enterprise Notification

##### Preconditions

1.  The User has access to the management GUI with the administrator
    role.

```{=html}
<!-- -->
```
1.  The route is configured in the database.

##### Post Conditions

1.  The route is removed from the database.

```{=html}
<!-- -->
```
1.  All endpoints associated with the deleted route are in the pending
    state.

##### Basic Flow Steps

1.  This use case begins when the User chooses to delete a route.

```{=html}
<!-- -->
```
175. The Management GUI provides a list of routes.

176. The User selects a route from the list of routes.

177. The User submits the deleted route.

178. The Data Access Layer sets all associated endpoints to a pending
     state.

179. The Data Access Layer sets all subscriptions associated with each
     endpoint to an inactive state.

180. The Data Access Layer sends a Route Deletion Message to the
     Extended Dissemination Capability.

181. The Data Access Layer logs the Subscription changes to the
     Enterprise Notification.

182. The Data Access Layer logs the Endpoint changes to the Enterprise
     Notification.

183. The Data Access Layer logs the Route deletion to the Enterprise
     Notification.

184. This Use Case ends when the User examines the status displayed on
     the Management GUI.

##### Alternate Flow Steps

> None.

##### Special Requirements

> None.

### Manage Endpoint Routing

#### Add Endpoint Routing

This use case flow details the steps needed to add an endpoint to a
route. The endpoint is attached to a route and denotes the final
destination for any product dissemination. A server is an extension of
an endpoint and therefore can also be the final destination for any
product dissemination.

The User will create the endpoint routing through use of the Management
GUI. The Management GUI will provide a list of endpoints and routes. The
User first selects an endpoint from a list of endpoints. The User then
selects a route from a list of routes. The User associates the endpoint
to the route and completes the configuration. The User submits the
endpoint routing to the database. The Management GUI displays the status
of the database operation.

This use case begins when the User chooses to add an endpoint to a
route. It ends when the User examines the status of the database action
displayed on the Management GUI.

![](media/image35.wmf){width="6.260416666666667in"
height="5.384722222222222in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  Management GUI

2.  Data Access Layer

3.  Database

4.  Enterprise Notification

##### Preconditions

1.  The User has access to the Management GUI with the administrator
    role.

```{=html}
<!-- -->
```
1.  The route information is loaded in the database.

2.  There exists an endpoint without any route associated to it.

##### Post Conditions

1.  The endpoint routing information is added in the AFWWS database.

##### Basic Flow Steps

1.  This use case begins when the User chooses to add an endpoint to a
    route.

2.  The Management GUI provides a list of endpoints to the User.

3.  The Management GUI provides a list of routes to the User.

4.  The User selects the endpoint from a list of endpoints.

5.  The User selects the route from a list of routes.

6.  The User associates the selected endpoint to the selected route.

7.  The User submits the configured endpoint routing to the database.

8.  The Data Access Layer logs the action to the Enterprise
    Notification.

9.  This Use Case ends when the User examines the status displayed on
    the Management GUI.

##### Alternate Flow Steps

> None.

##### Special Requirements

> None.

#### Edit Endpoint Routing

This use case flow details the steps needed to edit the endpoint routing
in the database. A route consists of a series of servers linked together
in a sequential order. The endpoint is attached to a route and denotes
the final destination for any product dissemination.

The User has the responsibility of changing the routing data when any
endpoint moves. Deployable endpoints require the User to disassociate
the endpoint from the existing route and associate it to a different
route.

The User will edit the endpoint routing through use of the Management
GUI. The Management GUI will provide a list of endpoints and routes. The
User first selects an endpoint from a list of endpoints. The User then
disassociates this endpoint from the route. The User selects a route
from a list of routes and associates the endpoint to it. The User
submits the endpoint routing modification to the database. The Data
Access Layer sends an Endpoint Routing Modification message to the
Extended Dissemination Capability. The Data Access Layers log the
modification with the Enterprise Notification. The Management GUI
displays the status of the database operation.

This use case begins when the User chooses to modify an existing
endpoint routing. It ends when the User examines the status of the
database action displayed on the Management GUI.

![](media/image36.wmf){width="5.906944444444444in"
height="5.177777777777778in"}

##### Actors

1.  User

```{=html}
<!-- -->
```
1.  Management GUI

2.  Data Access Layer

3.  Database

4.  Extended Dissemination Capability

5.  Enterprise Notification

##### Preconditions

1.  The User has access to the Management GUI with the administrator
    role.

```{=html}
<!-- -->
```
1.  The needed route data exists in the database.

2.  The endpoint routing data exists in the database.

##### Post Conditions

1.  The endpoint routing is updated in the database.

##### Basic Flow Steps

1.  This use case begins when the User chooses to modify the endpoint
    routing.

2.  The Management GUI provides a list of endpoints to the User.

3.  The Management GUI provides a list of routes to the User.

4.  The User selects the endpoint from the list of endpoints.

5.  The User disassociates the endpoint from its route.

6.  The User selects a new route from a list of routes.

7.  The User associates the endpoint with the new route.

8.  The User submits the endpoint routing updates to the system.

9.  The Data Access Layer sends an Endpoint Routing Modification message
    to Extended Dissemination Capability.

10. The Data Access Layer logs the action to the Enterprise
    Notification.

11. This Use Case ends when the User examines the status displayed on
    the Management GUI.

##### Alternate Flow Steps

> None.

##### Special Requirements

> None.

#### Delete Endpoint Routing

This Use Case flow details the steps needed to delete endpoint routing
in the database. The endpoint is attached to a route and denotes the
final destination for any product dissemination.

The User will delete the endpoint routing through use of the Management
GUI. The Management GUI will provide a list of endpoints. The User
selects an endpoint from this list. The User then disassociates the
selected endpoint from the route. The User submits the endpoint routing
for deletion. The Data Access Layer sets subscription to inactive and
the endpoint to a pending state. The Management GUI displays the status
of the database operation.

When an endpoint is disassociated from a route, the endpoint is
transitioned to a pending state waiting on the User to assign routing.
Endpoints in a pending state cannot have products associated with it
(i.e. subscription).

This use case begins when the User selects to delete an endpoint
routing. It ends when the User examines the status of the database
action displayed on the Management GUI.

![](media/image37.wmf){width="5.822916666666667in"
height="5.135416666666667in"}

##### Actors

1.  User

2.  Management GUI

3.  Data Access Layer

4.  Database

5.  Extended Dissemination Capability

6.  Enterprise Notification

##### Preconditions

1.  The User has access to the Management GUI with the administrator
    role.

2.  The endpoint routing exists in the database.

##### Post Conditions

1.  The endpoint routing is removed from the database.

##### Basic Flow Steps

1.  This use case begins when the User chooses to remove an endpoint
    from a route.

2.  The Management GUI provides a list of endpoint routing to the User.

3.  The Management GUI sets all active endpoints to read-only.

4.  The User selects the inactive endpoint from a list.

5.  The User disassociates the selected endpoint from the route.

6.  The User submits the deletion to the Data Access Layer.

7.  The Data Access Layer transitions the selected endpoint to a pending
    state.

8.  The Data Access Layer inactivates all subscriptions on the endpoint.

9.  The Data Access Layer logs the subscription state change to the
    Enterprise Notification.

10. The Data Access Layer sends an Endpoint Routing Deletion message to
    Extended Dissemination Capability.

11. The Data Access Layer logs the deletion to the Enterprise
    Notification.

12. This Use Case ends when the User examines the status displayed on
    the Management GUI.

##### Alternate Flow Steps

> None.

##### Special Requirements

> None.

# Requirements 

![](media/image38.wmf)