Terrestrial_usecases

This is version 14. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Terrestrial usecases

The following are the Usecases the terrestrial working group discussed during the July 2007 REAP Requirements Workshop. The group also conducted some informal ranking of these. First, usescases were given a 1-3 importance ranking, with 1 being most important. Second, of those cases ranked 1, group members voted for a few they felt were most important or should be implemented first.

1) Importance: 1, votes: 4
!Use Case Name: Detached Execution

Version:

Summary:

• User would like the ability to begin a Kepler workflow with laptop, detach/disconnect, and reconnect at a later time to check on execution status. Notifications may optionally be sent when workflow execution completes (how notifications will be sent will likely be configured in the workflow).
• Ability to launch from the command line in batch mode.
• Ability to re-attach to running job to check its progress.
• User would also like to check status, and stop workflow jobs via a web interface.

Preconditions:

• Have a complete workflow assembled.
• Distributed execution system has been built and running on an accessible server.
• Server has all software that the workflow requires (eg R, Matlab, etc)
• Other users are not currently connected to workflow with Write access.

Triggers:

• User launches job in batch mode. It will automatically detach at this point.
• From gui, user selects "detach".

Basic course of events:

• User designs workflow that includes notification system (eg uses Email Sender actor).
• User identifies server(s) and establishes connection.
• User executes workflow in either batch or gui mode (when workflow has graphical output, batch mode can handle this, eg ignore it, or write it out to eg pdfs)
• When workflow completes it sends notification.
• While job is running, user can reconnect to server and check status, alter settings, stop job or retrieve results.

Alternative paths:

• Instead of using Kepler, view progress on a webpage.
• Ability to suspend workflow without detaching from it

Postconditions:
Business rules:
Notes:
Author and date:

User has designed a workflow that specifies:

1. conditions under which a complete rerun of workflow should occur when user executes workflow (eg "if data sources I have marked have changed, a smart rerun cannot occur")
2. which intermediary derived data products to save for use by smart reruns

Summary:

Users want the ability to rerun certain workflows in a "smart" way, that is, without regenerating intermediary derived data products if the source data (and hence the derived data for non-stochastic models) have not changed. Some intermediate derived data products take a very long time to produce, hence it is beneficial to skip their generation when possible.
Triggers:

User executes a workflow that uses Smart Rerun features and all Smart Rerun criteria have been met.

Basic course of events:

Workflow developer designs a workflow that makes use of Smart Rerun components.

Upon execution of this workflow, Smart Rerun components check to see if their input data sources have changed (possibly the user can also specify conditions which must also be met). If these data sources have changed (or are being used for the first time), components (re)produce derived data products and save those that are marked as Smart Rerun derived data products. If data sources have not changed, and previously saved derived data products exist, a Smart Rerun can occur reusing these existing products. Special considerations for stochastic systems must be taken into account in the design of this usecase (do we allow Smart Reruns for certain stochastic models?).

Alternative paths:

• It is possible a user would also like the ability to do a Smart Rerun even if Smart Rerun criteria are not met, ie they might want to ignore the fact that data sources have changed and reuse existing derived data products to test something else.

Postconditions:

Intermediary derived data products produced by Smart Rerun actors are saved.

Business rules:
Notes:
Author and date:

Version:
Summary:

Users want to be able to save intermediate derived datasets.

Preconditions:
Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes: This usecase can be seen as required by the "Smart Rerun", "Manage a group of model runs", and "Archive a complete end to end run" usecases
Author and date:

Users would like the ability to create a "publication ready archive"--an archive that contains the Kepler workflow, all required inputs (data sources like database tables are included), and all produced output. For example, at the completion of a study, a user can produce this archive and submit it (or a link to it) alongside their paper to peers and journals.

Preconditions:

• User has created workflow that contains everything needed (eg data sources).
• User documents any external software the workflow requires

Triggers:

User exports workflow

Basic course of events:

User creates a workflow. User turns on "publication ready archive" mode. User runs workflow, and exports to an archive at completion.

Alternative paths:

User uses features from "Smart Rerun", "Manage a group of model runs", and "save intermediate derived data products" usecase (ie a special "publication ready archive" mode might not be required).

Postconditions:

Business rules:
Notes:

A specific "publication ready archive" option would not be required if requirements for usecases mentioned in Alt Paths are implemented.
Author and date:

Users would like the ability to use a database (or more likely simply some data from a table in a database) in two ways.

1. User can download a snapshot of the database or data from database and in all consecutive workflow runs, operate on this data snapshot
2. Each time workflow is run, the (potentially dynamic) database is queried and the resulting response is used.

Preconditions:

• User has setup a workflow that uses a database actor
• User has configured database actor to either snapshot or realtime mode.

Triggers:

Workflow containing database actor is run.

Basic course of events:

Alternative paths:
Postconditions:

If Snapshot feature is used, data snapshot is saved.

Business rules:
Notes:
Author and date:

Users would like to be able to produce annotations that are visually closely coupled with actors. When an actor is dragged around the campus, if it has an associated annotation, this annotation moves alongside it. This does not require a graphical link (eg line or box) that groups the two, but this could be done.

Preconditions:

A component has been created with which to associate an annotation.

Triggers:
Basic course of events:

User creates a component and chooses to create an associated annotation for it.

Alternative paths:

Another way to approach this would be mouseover "alt text" popups.

Postconditions:
Business rules:
Notes:
Author and date:

Users want the ability to easily merge many different data sources into one. For example, in the REAP terrestrial case study users might want to merge a) data in differently formatted excel and text files b) data from near-realtime streams and c) data pulled from an archive. Users want this process to convert units if needs be.

Preconditions:

An instance of data-merge component has been created with inputs connected to desired data sources.

Triggers:

User executes workflow.

Basic course of events:

User creates an instance of data-merge component and connects its input ports to desired data sources. User specifies certain properties in the data-merge actor regarding how to merge data (eg how to convert units, if interpolation or decimation should occur, which differently names fields correspond, etc). Depending on how complex the data-merge actor becomes, it may have to require user interaction.

Alternative paths:

User merges data themselves :)

Postconditions:

Merged derived source data product is produced--and potentially saved.

Business rules:
Notes:
Author and date:

DatabaseQuery actor has different output ports than metacat database actors -- users would like these actors to be more consistent. Users would also like to be able to view a database and its tables with this integrated actor.

Preconditions:
Triggers:
Basic course of events:

Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Users would like to be able to design workflows that send out alerts when certain criteria are met.

Users would typically like these kinds of workflows to run automatically and periodically on a cron or cron-like system that easy to setup.

Examples:

• monitor rainfall thresholds
• light monitoring, eg if ambient light < ground level light, send email.
• monitor if animals go outside a certain radius or bounding box
• monitor the proximity of different animals, eg mating events

Preconditions:
Triggers:

• A specified threshold or condition has been reached.
• A certain type of error has occurred

Basic course of events:

• User designs an event monitoring workflow and sets it to run indefinitely or periodically
• Workflow continously or periodically runs. workflow checks if certain conditions are true.
• If a condition is met, a notification is sent via channel specified in workflow (eg email)

Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Users would like to be able to easily search through a workflow for a certain actor, or type of actor. This would facilitate finding actors buried deep within nested composites.

Preconditions:
Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Users would like to be able to view a workflow in collapsable tree (hierarchical) form in addition to the current canvas view. Users would also like to the ability to open a composite actor into a new tab, instead of a whole new Kepler window.

Preconditions:
Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

12)Importance: 1, votes: 1
!Use Case Name: Manage a group of model runs
Version:
Summary:

Users would like to be able to design a workflow that allows for the management a group of model runs. This means:

• allowing user to easily define multi-dimensional parameter sweep
• allowing user to change course by redefining the parameter sweep part-way through execution
• saving all important aspects of each run (a log of parameters used, changes made, data products produced (including graphs))
• grouping sets of products produced in an understandable way (eg legend of params used on each graph, listed in metadata of products produced, output files grouped by name or directories, etc)
• user might like ability to specify which intermediate data products are saved.
• ability to read parameter space from a file that user has configured
• allow for "irregular sweeps"
• allow random parameters

This might be accomplished with a parameter sweep actor.

Preconditions:
Triggers:
Basic course of events:

User develops workflow that includes a Parameter Sweep component. The input port(s) of this component are connected to parameters or parameter source(s) like a text file.

Alternative paths:

User designs a workflow that uses and changes (existing) Parameter components.

Postconditions:
Business rules:
Notes:
Author and date:

Version:
Summary:
Preconditions:
Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Users would like to easily wrap an external program in Kepler. By "wrap" we mean create a simple workflow that consists of being able to run an external program that has already been developed, eg a C or Fortran program.

Users would like either or both of the following:

1. an instruction set / tutorial for easily "wrapping" an external program into a workflow in Kepler
2. a wizard inside Kepler that takes them through the steps of producing this workflow.

Preconditions:

Working external program has already been written.

Triggers:

User runs wizard or user opens tutorial.

Basic course of events:

User executes wizard inside Kepler, points it at their external program, and configures any required settings via the wizard.

Alternative paths:

User reads tutorial that explains how to "wrap" external programs and builds the workflow.

Postconditions:
Business rules:
Notes:
Author and date:

Users want an easy way to create and share workflows with others. This means making sure exporting, emailing, and importing workflows is painless, or the submission of workflows/actors to a repository that others can import from is painless.

Preconditions:
Triggers:
Basic course of events:

1. User1 creates component or workflow.
2. User1 exports or publishes component or workflow.
3. User2 imports component or workflow.

Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Version:
Summary:

Users would like search functionality improved to utilize keywords, categories, author, natural language, tagging.

Preconditions:
Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Version:
Summary:
Preconditions:
Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Users would like to use Kepler as a teaching tool. This means adding features such as:

• ability to "lock" certain components away from students
• improving Kepler's animation (eg show parameters as they change) so live demos are more expressive
• improving Kepler's error messages.

Preconditions:
Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes: There was a lock of discussion on how to "lock" things. with ideas ranging from simply changing the icon or color of the component to signify the user should not touch it, to more difficult to circumvent restrictions like a password.
Author and date:

Users would like a set of components to do common ecological functions (ie mean or sum...) over temporal and spatial scales

Preconditions:

If ecologists want to create some of these: improvements to workflow and component submission to repository process have been made.

Triggers:
Basic course of events:

User makes use of new ecological components in library as they would any other.

Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Users would like a set of FakeData Generator Actors appropriate to the REAP Case Studies. A FakeData actor should produce data in the same way a real data source would. For example, a "FakeData_CR800_Temperature" Actor might produce a datastream of temperature data at 1 "sample" per minute. The actual data in the datastream should be indecipherable from a real temperature stream coming out of a Campbell CR800 datalogger deployed in the field. Somewhere in the metadata however, a FakeData Generator Actor should clearly identify itself (as being fake).

Preconditions:

Depending on how exactly we wish to simulate certain datalogger datastreams, these specs need to be available during the development of this/these actor(s).

Triggers:
Basic course of events:

• User drags actor to canvas like any other data source.
• User configures actor to specify it as a certain type of data source (eg Campbell temperature stream) with sampling characteristics.

Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Users would like to be able to produce 3d plots with Kepler. (ggobi, gnuplot, java3d ?)

Preconditions:

3d visualization software is installed on user's machine.

Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Users would like an Iterator Actor that iterates a workflow, or parts of a workflow in a smart way. See Paramater Sweep Usecase.

Preconditions:
Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Allow this different technique for running models. Can not use if model is stochastic.

Preconditions:

An understanding of mcmc. :)

Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes: (see winbugs and R2WinBUGS)
Author and date:

Users would like to be able to add breakpoints in a workflow. When a breakpoint is reached, workflow execution is paused or stopped. Users would also like breakpoints to be conditional, eg a breakpoint might only pause or stop execution once a certain condition (like equilibrium) has been reached.

Preconditions:
Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Users would like an easy way to debug workflows. Some ideas on this: a special debug output port on all actors; or a specific debug actor (most workflow developers make extensive use of the display actor to verify output after each step as they build workflows--new users might not think of this, an actor named or tagged Debug might be of use)

Preconditions:
Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Version:
Summary:

Users would like Kepler's error messages to be more understandable.

Preconditions:
Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date:

Version:
Summary:

Users would like to be able to mark certain components inactive/disabled such that they can sit on the canvas but not do anything. Presumably a visual key designating an actor is disabled would be very helpful (eg "greyed out").

Preconditions:
Triggers:
Basic course of events:
Alternative paths:
Postconditions:
Business rules:
Notes:
Author and date: