Get status of query process
Use Case Number |
INIT1SD2.pm7.1 |
Brief Description |
When a long-running query is submitted to a number of different federated services, it is desirable to be able to provide users with a status update on the progress of the query, including which services have completed, how much data has been returned, and (if possible) how much work is left. |
Actor(s) for this particular use case |
Cancer Researcher |
Pre-condition |
A number of services are available upon which a federated query can be performed. |
Post condition |
The user is updated with the status of the query. |
Steps to take |
|
Alternate Flow |
None. |
Priority |
Medium. |
Associated Links |
|
Fit criterion/Acceptance Criterion |
Minimally, the user should be informed on which services have completed execution of the query, which are still working on the query, and how much time has passed for each service. |
Get intermediate query results
Use Case Number |
INIT1SD2.pm7.2 |
Brief Description |
After receiving a status update that a federated query has completed on some services, the user may want to fetch and view the results from the completed sub-queries. |
Actor(s) for this particular use case |
Cancer Researcher |
Pre-condition |
A federated query has been submitted to multiple services and a subset of them have completed. |
Post condition |
The user receives intermediate data from the completed sub-queries. |
Steps to take |
|
Alternate Flow |
None. |
Priority |
Medium. |
Associated Links |
|
Fit criterion/Acceptance Criterion |
The Cancer Researcher can view intermediate results in order to determine whether to continue the processing of the federated query. |
Cancel portions of a query
Use Case Number |
INIT1SD2.pm7.3 |
Brief Description |
After reviewing intermediate results or after a federated query takes too long to complete at some number of services, the Cancer Researcher may choose to cancel the processing of the query at any number of the services. |
Actor(s) for this particular use case |
Cancer Researcher |
Pre-condition |
A federated query is running at a number of services. |
Post condition |
The selected services have canceled processing of the federated query, and data is available at all services that have completed |
Steps to take |
|
Alternate Flow |
The Cancer Researcher sets a time limit to set on the query, and the status update returns whether the time limit has been met and the query has been canceled (see use case below). |
Priority |
Medium. |
Associated Links |
|
Fit criterion/Acceptance Criterion |
Query processing is completed totally, but the status of canceled remains for some period of time (as determined by the service or the query itself). |
Interrogate a service for additional data information
Use Case Number |
INIT1SD2.pm7.4 |
Brief Description |
Before issuing a federated query, the user may want to determine which services to query based upon criteria such as how many data objects are stored within the service, etc. |
Actor(s) for this particular use case |
Cancer Researcher |
Pre-condition |
A number of services are available upon which a federated query can be performed. |
Post condition |
The user has extra information on the data stored by each service referenced by the federated query. |
Steps to take |
|
Alternate Flow |
None. |
Priority |
Low. |
Associated Links |
|
Fit criterion/Acceptance Criterion |
It is necessary that at least the number of data objects is returned, but it would also be desirable to know which data elements from the information model have associated data. |
Specify complexity of federated joins
Use Case Number |
INIT1SD2.pm7.4 |
Brief Description |
Before issuing a query, a user may want to specify constraints on it that limits its complexity in order to make sure that it completes in satisfactory time. |
Actor(s) for this particular use case |
Cancer Researcher |
Pre-condition |
A number of services are available upon which a federated query can be performed. |
Post condition |
The federated query is augmented with complexity limits |
Steps to take |
|
Alternate Flow |
The Cancer Researcher views the default complexity limit factors (from the query tool and from the services themselves) and modifies them if desired. |
Priority |
Medium |
Associated Links |
|
Fit criterion/Acceptance Criterion |
Minimally, a user must be able to determine that joins across different services remain within an organization rather than go across organizations (because there would not be common identifiers). |
Customize complexity of supported queries
Use Case Number |
INIT1SD2.pm7.5 |
Brief Description |
|
Actor(s) for this particular use case |
Software Engineer |
Pre-condition |
|
Post condition |
|
Steps to take |
1. |
Alternate Flow |
|
Priority |
|
Associated Links |
|
Fit criterion/Acceptance Criterion |
|