| At line 5 added 1 line. |
| + !__Use Case Name:__ Detached Execution |
| Removed line 7 |
| - \\!__Use Case Name:__ Detached Execution |
| Lines 9-47 were replaced by line 9 |
| - \\__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:__ |
| - |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: Smart Reruns |
| Removed lines 49-63 |
| - \\!__Use Case Name__: Smart Reruns |
| - \\__Version:__ |
| - \\__Preconditions:__ |
| - |
| - User has designed a workflow that specifies: |
| - # 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") |
| - # 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. |
| Lines 65-86 were replaced by line 12 |
| - \\__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:__ |
| - |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: Optional archiving of intermediate derived datasets. |
| Removed lines 88-103 |
| - \\!__Use Case Name__: Optional archiving of intermediate derived datasets. |
| - |
| - \\__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:__ |
| - |
| Lines 105-108 were replaced by line 15 |
| - |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: Archive a complete end to end run ("publication ready archive") |
| Removed lines 110-137 |
| - \\!__Use Case Name__: Archive a complete end to end run ("publication ready archive") |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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:__ |
| Lines 139-146 were replaced by line 18 |
| - A specific "publication ready archive" option would not be required if requirements for usecases mentioned in Alt Paths are implemented. |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: Database actor option: Snapshot |
| Removed lines 148-170 |
| - \\!__Use Case Name__: Database actor option: Snapshot |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like the ability to use a database (or more likely simply some data from a table in a database) in two ways. |
| - # User can download a snapshot of the database or data from database and in all consecutive workflow runs, operate on this data snapshot |
| - # 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:__ |
| Lines 172-184 were replaced by line 21 |
| - If Snapshot feature is used, data snapshot is saved. |
| - |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - |
| - |
| - ---- |
| + !__Use Case Name__: Actor specific annotations (gui linked) |
| Removed lines 186-203 |
| - \\!__Use Case Name__: Actor specific annotations (gui linked) |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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. |
| Lines 205-213 were replaced by line 24 |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: Actor for Data-Merge for specific product |
| Removed lines 215-237 |
| - \\!__Use Case Name__: Actor for Data-Merge for specific product |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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 :) |
| Lines 239-252 were replaced by line 27 |
| - \\__Postconditions:__ |
| - |
| - Merged derived source data product is produced--and potentially saved. |
| - |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - |
| - ---- |
| + !__Use Case Name__: Integrate database actors |
| Removed lines 254-273 |
| - \\!__Use Case Name__: Integrate database actors |
| - \\__Version:__ |
| - \\__Summary:__ make database actors more consistent. |
| - |
| - 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:__ |
| - |
| - |
| Lines 275-278 were replaced by line 30 |
| - \\ |
| - |
| - |
| - ---- |
| + !__Use Case Name__: Event Notification Monitoring system |
| Removed lines 280-314 |
| - \\!__Use Case Name__: Event Notification Monitoring system |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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:__ |
| - |
| - |
| - \\ |
| Line 316 was replaced by line 33 |
| - ---- |
| + !__Use Case Name__: Search through workflow for a certain type of actor |
| Removed lines 318-331 |
| - \\!__Use Case Name__: Search through workflow for a certain type of actor |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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:__ |
| Lines 333-335 were replaced by line 36 |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: Different workflow view |
| Removed lines 337-356 |
| - \\!__Use Case Name__: Different workflow view |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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:__ |
| - |
| - |
| - |
| - \\ |
| - |
| Lines 358-359 were replaced by line 39 |
| - ---- |
| - |
| + !__Use Case Name__: Manage a group of model runs |
| Removed lines 361-385 |
| - \\!__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:__ |
| Lines 387-397 were replaced by line 42 |
| - User designs a workflow that uses and changes (existing) Parameter components. |
| - |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: Workflows need to accommodate sub-workflows that operate at different frequencies |
| Removed lines 399-412 |
| - \\!__Use Case Name__: Workflows need to accommodate sub-workflows that operate at different frequencies |
| - |
| - \\__Version:__ |
| - \\__Summary:__ |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| Lines 414-417 were replaced by line 45 |
| - \\ |
| - |
| - |
| - ---- |
| + !__Use Case Name__: Tutorial or Wizard for wrapping external programs |
| Removed lines 419-431 |
| - \\!__Use Case Name__: Tutorial or Wizard for wrapping external programs |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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: |
| - # an instruction set / tutorial for easily "wrapping" an external program into a workflow in Kepler |
| - # a wizard inside Kepler that takes them through the steps of producing this workflow. |
| - |
| - \\__Preconditions:__ |
| - |
| - Working external program has already been written. |
| Lines 433-455 were replaced by line 48 |
| - \\__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:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - |
| - ---- |
| + !__Use Case Name__: Easily create and share workflows and actors |
| Removed lines 457-469 |
| - \\!__Use Case Name__: Easily create and share workflows and actors |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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:__ |
| - |
| - # User1 creates component or workflow. |
| - # User1 exports or publishes component or workflow. |
| - # User2 imports component or workflow. |
| Lines 471-480 were replaced by line 51 |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: Improve component search. |
| Removed lines 482-497 |
| - \\!__Use Case Name__: Improve component search. |
| - |
| - \\__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:__ |
| - |
| Lines 499-504 were replaced by line 54 |
| - |
| - \\ |
| - |
| - |
| - |
| - ---- |
| + !__Use Case Name__: facilitate peer review process |
| Removed lines 506-518 |
| - \\!__Use Case Name__: facilitate peer review process |
| - |
| - \\__Version:__ |
| - \\__Summary:__ |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| Lines 520-524 were replaced by line 57 |
| - |
| - \\ |
| - |
| - |
| - ---- |
| + !__Use Case Name__: Use Kepler as a teaching tool |
| Removed lines 526-544 |
| - \\!__Use Case Name__: Use Kepler as a teaching tool |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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:__ |
| - |
| - \\ |
| Lines 546-547 were replaced by line 60 |
| - |
| - ---- |
| + !__Use Case Name__: Ecological Actors |
| Removed lines 549-555 |
| - \\!__Use Case Name__: Ecological Actors |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like a set of components to do common ecological functions (ie mean or sum...) over temporal and spatial scales |
| - |
| - \\__Preconditions:__ |
| Lines 557-573 were replaced by line 63 |
| - 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:__ |
| - |
| - |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: FakeData Generator Actor(s) |
| Removed lines 575-579 |
| - \\!__Use Case Name__: FakeData Generator Actor(s) |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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). |
| Lines 581-600 were replaced by line 66 |
| - \\__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:__ |
| - |
| - |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: 3d plots |
| Removed lines 602-622 |
| - \\!__Use Case Name__: 3d plots |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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:__ |
| - |
| - \\ |
| - |
| Lines 624-627 were replaced by line 69 |
| - ---- |
| - \\!__Use Case Name__: Iterator wrapper actor |
| - \\__Version:__ |
| - \\__Summary:__ |
| + !__Use Case Name__: Iterator wrapper actor |
| Lines 629-645 were replaced by line 71 |
| - 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:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - |
| - ---- |
| + !__Use Case Name__: Markov Chain Monte Carlo (mcmc) |
| Removed lines 647-651 |
| - \\!__Use Case Name__: Markov Chain Monte Carlo (mcmc) |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Allow this different technique for running models. Can not use if model is stochastic. |
| Lines 653-667 were replaced by line 74 |
| - \\__Preconditions:__ |
| - |
| - An understanding of mcmc. :) |
| - |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ (see winbugs and R2WinBUGS) |
| - \\__Author and date:__ |
| - |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: Breakpoints |
| Removed lines 669-682 |
| - \\!__Use Case Name__: Breakpoints |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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:__ |
| Lines 684-686 were replaced by line 77 |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: Debugging |
| Removed lines 688-701 |
| - \\!__Use Case Name__: Debugging |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - 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:__ |
| Line 703 was replaced by line 80 |
| - ---- |
| + !__Use Case Name__: Improved error messages. |
| Removed lines 705-710 |
| - \\!__Use Case Name__: Improved error messages. |
| - |
| - \\__Version:__ |
| - \\__Summary:__ |
| - |
| - Users would like Kepler's error messages to be more understandable. |
| Lines 712-725 were replaced by line 83 |
| - \\__Preconditions:__ |
| - \\__Triggers:__ |
| - \\__Basic course of events:__ |
| - \\__Alternative paths:__ |
| - \\__Postconditions:__ |
| - \\__Business rules:__ |
| - \\__Notes:__ |
| - \\__Author and date:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - ---- |
| + !__Use Case Name__: Disable actors |
| Removed lines 727-748 |
| - \\!__Use Case Name__: Disable actors |
| - |
| - \\__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:__ |
| - |
| - |
| - |
| - \\ |
| - |
| - |
| - |
