These are more like scenarios or flows than real use cases in formal UML terms, but they serve a useful purpose as both. We don't want to be over formal, and probably code is being written and tested at the same time as these use cases. But there are many stakeholders in this project, and use cases are a useful resource to make sure they are all agreed on scope and certain implementation details.
The following actors are involved in the use cases (Container and Client being the most common / important).
Code written by the batch developer.
One aim us that the client is a POJO - the batch behaviour, boundary conditions, transactions etc. can be dealt with by the Container in such as way that the client does not need to know about them. The client may have access to framework abstractions, like templated data sources (JdbcTemplate etc.), but these should work the same whether they are in a batch or not.
An application that converts user requests for batch jobs into running processes. Container concerns are robustness, traceability, manageability.
The Framework is the infrastructure code that the Container depends on, and possibly spi implementations where knowledge of the non-business logic resides.
The Framework provides two kinds of infrastruture (as per usual Spring cornerstones AOP and Portable Service Abstractions):
The batch operator is not a developer. Tools are provided for the Operator to be able to stop and start a batch, and to monitor the progress and status of on ongoing or finished batch.
The Operator has technical skills, e.g. a member of an application support team, but may need help with business-related decisions. For instance if input data are bad, he would not expect to be able to fix them alone because they might be bad for a business reason.