End-user: Wants to execute a computation on a resource accessible by the user. The computation optionally requires a set of input files to be made available to the computational resource. The user wants the output of the computation to be made available in an accessible location.
Computational Resource Owner: Wants to make available a computational resource to End-users through the System. Wants to ensure only authorised users can use the resource. Wants to reuse the local scheduling environment to make best resource allocation. The local scheduling environment may retain its autonomy from the System (i.e. users can still use the local scheduling system directly).
Storage Resource Owner: Wants to make file and file system available to End-user and Computational Resource Owner.
Preconditions
End-user is identified and authenticated to the system
End-user has made available the input files required by the computation to one or many Storage resource owners.
Computational Resource Owner has already instantiated a System ready to be used by the End-user. The System location is advertised to the End-user.
Postconditions
Job request is recorded by the system and eventually executed when the required resource becomes available. After successful execution, output files are made available to the End-user from the designated Storage Resource Owner.
Main Success Scenarios and Steps
End-user collects the requirements of the computation. It should include application parameters, input and output files requirements, dependencies and system requirements.
End-user enters the Job Requirements into the System Tool.
The System managed by the Computational Resource Owners records the Job Requirements. and issues the End-user with an identifier to uniquely identify the job request.
The System transfers the file(s) from the designated Storage Resource Owner(s) or prepare the file system according to the Job Requirements. Job state is advanced.
The System launches the job onto available resources. Job state is advanced.
The System transfers or ensures the output file(s) are made available to the Storage Resource Owner(s) at the end of the execution. Job state is updated to successful.
Extensions
3a. End-user has specified an invalid Job Requirements:
The System signals an error. The Job Request will not be recorded.
All remaining steps are skipped.
4 - 6a At any time, the System fails:
The Computational Resource Owner restarts the System.
The System restarts the execution at the beginning of the stage which failed.
4a. Any input file fails to be obtained from the Storage Resource Owner:
The System updates the job state to failure.
Steps 5 and 6 are skipped.
5a. The System fails to find matching resource:
The Job Request stays in the system until a matching resource is available.
5b. The System fails to launch the computation due to an error with the underlying local scheduler:
The System updates the job state to failure.
Step 6 is skipped.
Special Requirements
The System must be able to allow End-users to submit Job Requests concurrently.
The System Tool must be replaceable by other third-party tools, which can interact with the System using the same System Protocol.
The Job Requirement must be specified in a standard language. The End-user must be able to create the Job Requirement without knowing the propeitary details of the underlying local scheduler used by the System.
Use Case 2: Monitor Job
Primary Actor
End-user
Stakeholders and Interests
End-user: Wants to monitor the state of the job submitted per Use Case 1.
Computational Resource Owner: Wants to make available the status of the computation executing in the local scheduling system.
Preconditions
End-user is identified and authenticated to the system
End-user has successfully submitted a job to the System and obtained the job identifier.
Postconditions
Job status is presented to the End User. The job status should contain the current state, chronological snapshots of the events signalled during execution, and additional properties (e.g. resource usage, exit code) specific to the computation.
Main Success Scenarios and Steps
End-user enters the Job Identifier into the System Tool.
System checks whether the End-user is authorised to obtain status of the computation identified by the Job Identifier.
System presents the job status to the End-user.
Extensions
2a. End-user has specified an invalid Job Identifier:
The System signals an error.
All remaining steps are skipped.
2b. Job Identifier does not denote a known job to the System:
The System signals an error.
All remaining steps are skipped.
2c. End-user is not authorised to obtain status of the job identified by the Job Identifier:
The System signals an error.
All remaining steps are skipped.
Special Requirements
The System must be able to allow End-users to issue Monitoring Requests concurrently.
The System Tool must be replaceable by other third-party tools, which can interact with the System using the same System Protocol.
Use Case 3: Terminate Job
Primary Actor
End-user
Stakeholders and Interests
End-user: Wants to abruptly terminated a submitted job per Use Case 1.
Computational Resource Owner: Wants to clean up the resources used by the executing job.
Preconditions
End-user is identified and authenticated to the system
End-user has successfully submitted a job to the System and obtained the job identifier. The job has not been completed.
Postconditions
The job will go into the terminating sequence. A terminating job might take time to completely terminate and free up resources. This should happen asynchrounsly to the user's action.
Main Success Scenarios and Steps
End-user enters the Job Identifier into the System Tool.
System checks whether the End-user is authorised to obtain status of the computation identified by the Job Identifier.
System initiates the termination phase of the job. Any remaining stage of the job is bypassed (file copying, etc.). The system will clean up the resources used by the job.
Extensions
2a. End-user has specified an invalid Job Identifier:
The System signals an error.
All remaining steps are skipped.
2b. Job Identifier does not denote a known job to the System:
The System signals an error.
All remaining steps are skipped.
2c. End-user is not authorised to obtain status of the job identified by the Job Identifier:
The System signals an error.
All remaining steps are skipped.
2d. Job has already completed:
The terminating request from the User is ignored.
Special Requirements
The System must be able to allow End-users to issue termination requests multiple times. Only the first request is processed.
The System Tool must be replaceable by other third-party tools, which can interact with the System using the same System Protocol.
