Describe obligatory state model for given resource type.
|Actors||State Model Developer|
|Uses||UC.R2.08 Manage Instrument Lifecycle|
|Is Used By|
|Is Extended By|
|In Acceptance Scenarios||AS.R2.01B Define Marine Observatory Policies, AS.R2.02C Instrument Life Cycle Support, AS.R2.04B Curate Data Products|
|Technical Notes||Although many of these are development steps rather than system operation steps,
the final steps show system execution using the resulting product.
|Primary Service||Resource Lifecycle Services|
|UC Status||Mapped + Ready|
This information summarizes the Use Case functionality.
Define a state model with activities for one specific type of Integrated Observatory resource, such that all resources of this type then follow this state model and activity flow. (A 'resource' is any system entity with capabilities or state.) Take a resource of the chosen type through the activities and states. Integrate with UI (e.g., for display and control) and processing (e.g., leverage the resource type using policy).
- There is a life cycle model (template) upon which the individual resource type's life cycle is based.
- The resource life cycle model is a necessary approach to allow us to manage life cycle issues across all our assets.
A resource type (the 'target resource') has been identified for which life cycle states are to be identified.
- <2> State Model Developer starts with generic Resource Life Cycle state model, and identifies new states or substates appropriate to the particular target resource.
- <2> State Model Developer also determines new permitted transitions between states (and any applicable constraints).
- <2> State Model Developer encodes states and state transitions in appropriate specification format to create a Life Cycle State Model for that resource type.
- <2> State Model Developer triggers the State Model repository service to register or reload the defined state model.
- This step can occur after the software development steps below.
- A technique to directly submit the newly defined state model is also acceptable.
- <3> State Model Developer creates software components/services that appropriately transition the resource through its different states.
- GUIs enable operator control of most transitions (i.e., a user commands the resource to change its state), while some transitions may occur as a result of internal system operations.
- An Integrated Observatory Operator can demonstrate application states and substates (possibly on a test system).
- In later releases, policy and governance may be automatically applied on each state transition, to confirm it is appropriate and consistent with the state model for the target resource.
- After the necessary software components/services are deployed, the Integrated Observatory Operator moves a resource of the selected type through its life cycle states.
- In later releases, policy and governance may cause a resource's state transitions.
- UC.R2.08 Manage Instrument Lifecycle is a specific example of a resource type moving through its life cycle states.
- Integrated Observatory Operator monitors the resource state in a user interface that displays the states.
Resource Life Cycle state model for that resource type is shown to be fully accessible and operational.
These comments provide additional context (usually quite technical) for editors of the use case.
This use case should be extended to satisfy various DOORS requirements regarding resource lifecycle; include all of the states defined in the generic lifecycle (swim lane diagram ) and any others specifically mentioned in the requirements; also include notification for resource activation and ensuring no resource interference.