Add attributes to a single data set

From OPeNDAP Documentation
Revision as of 20:39, 7 April 2009 by Jimg (talk | contribs) (→‎Goal)
⧼opendap2-jumptonavigation⧽

Back: AIS Using NcML

Description

Give a short descriptive name for the use case to serve as a unique identifier. Consider goal-driven use case name.

Add attributes to a single data set. The attributes appear in a DAS or DDX when the server is used to access a URL that references a NcML file but they do not otherwise appear 'unusual' in any way (the attributes could just as easily have been part of a netCDF, HDF4, et c., file).

Goal

The goal briefly describes what the user intends to achieve with this use case.

Summary

Give a summary of the use case to capture the essence of the use case (no longer than a page). It provides a quick overview and includes the goal and principal actor.

A person decides that the want to server a data set using WCS. They first examine the data set, maybe using DAP to look at the dataset's variables and attributes or maybe using some other tools, and determine what information to add. In all cases they decide to only add attributes and only attributes in OtherXML elements. Using information about the XML-encoded information needed by the WCS front-end, they write it into the .ncml file. The handler effectively makes this another URL which can be dereferenced.

Actors

List actors, people or things outside the system that either acts on the system (primary actors) or is acted on by the system (secondary actors). Primary actors are ones that invoke the use case and benefit from the result. Identify sensors, models, portals and relevant data resources. Identify the primary actor and briefly describe role.

  1. The person who writes the NcML file
  2. The BES NcML handler
  3. The BES
  4. The WCS front-end

Preconditions

Here we state any assumptions about the state of the system that must be met for the trigger (below) to initiate the use case. Any assumptions about other systems can also be stated here, for example, weather conditions. List all preconditions.

  1. The WCS Front-end is part of this Hyrax installation
  2. The NcML handler has been installed and configured

Triggers

Here we describe in detail the event or events that brings about the execution of this use case. Triggers can be external, temporal, or internal. They can be single events or when a set of conditions are met, List all triggers and relationships.

Basic Flow

Often referred to as the primary scenario or course of events. In the basic flow we describe the flow that would be followed if the use case where to follow its main plot from start to end. Error states or alternate states that might be highlighted are not included here. This gives any browser of the document a quick view of how the system will work. Here the flow can be documented as a list, a conversation or as a story.(as much as required)

  1. The user/configurer decides to make a data set available using the WCS front-end
  2. They look at the WCS documentation to see what information it needs and how that information should be represented.
  3. They look at the data source and figure out what of the information needed is already there in the necessary form and what needs to be added
  4. They add the extra information to a NcML file that references the original data set.
  5. They store the new NcML file in a directory that the BES can use to 'serve it using the NcML handler'. This probably means any directory under the BES' DocumentRoot directory (since the BES uses regular expressions to match data sets to handlers, there's a fair amount of latitude to where the NcML file is stored).
  6. They test the result.

Alternate Flow

Here we give any alternate flows that might occur. May include flows that involve error conditions. Or flows that fall outside of the basic flow.

Post Conditions

Here we give any conditions that will be true of the state of the system after the use case has been completed.

Activity Diagram

Here a diagram is given to show the flow of events that surrounds the use case. It might be that text is a more useful way of describing the use case. However often a picture speaks a 1000 words.

Notes

There is always some piece of information that is required that has no other place to go. This is the place for that information.

Resources

In order to support the capabilities described in this Use Case, a set of resources must be available and/or configured. These resources include data and services, and the systems that offer them. This section will call out examples of these resources.

Other Resources

Resource Owner Description Availability Source System
(sensor name) Organization that owns/ manages resource Short description of the resource How often the resource is available Name of system which provides resource