Use case edit suggestions#18
Conversation
|
|
||
| | Field | Content | | ||
| |-------|---------| | ||
| | **Actor(s)** | Non-Python clients (C++, Julia, JavaScript dashboards), external tools | |
There was a problem hiding this comment.
From the ngVLA design document
Python is the lingua franca in the astronomy domain. DMS staff have
considerable experience primarily with Python and secondarily with
C++.
Even though it admits Python as the primary language of use, the intentional mention of C++ (not to mention how intertwined it is in CASA currently), this requirement at least is implied. There are also many in-scope requirements referencing the use of dashboards, which again emphasizes (or at least implies) a language-agnostic interface availability.
There was a problem hiding this comment.
Could you walk me through how this is implied? It isn't obvious to me.
I could also see interfacing with external systems being done by some kind of a service layer and I guess it depends on where we "draw the line" whether we see this as part of the context or separate.
There was a problem hiding this comment.
Notes from zoom discussion with Tom:
Different perspectives:
(internal) pipeline perspective: internal object maintains state
(external) i.e. PL Driver: needed to make a subprocess so it could be monitored while running to be able to respond to events like "the process is hung"
Maybe clarify the multi-language requirement with stakeholders? Is this actually a requirement? Trying to understand.
There was a problem hiding this comment.
I left this in the appendix for now but am open to moving it back to GAP or reaching out for clarification either now or when we send out the draft.
There was a problem hiding this comment.
This could perhaps be split into two separate use cases: one for tracking execution progress and stage history and the other for preserving per-stage execution record for resume, audit, and diagnosis.
There was a problem hiding this comment.
Good point, I'm splitting this in two and you can let me know what you think about the split version.
…t UC-06 into two use cases and update use case numbering
| |-------|---------| | ||
| | **Actor(s)** | QA dashboards, monitoring tools, archive ingest systems, scheduling systems | | ||
| | **Summary** | External systems need access to current processing state — including current stage, processing time, QA results, and lifecycle transitions — without relying on offline product files. The system must expose sufficient state for these consumers to track and respond to processing status in a timely way. | | ||
| | **Summary** | External systems need access to current processing state — including current stage, processing time, QA results, and lifecycle transitions — without relying on offline product files. The `Context` must expose sufficient state for these consumers to track and respond to processing status in a timely way. | |
There was a problem hiding this comment.
I don't think we should use Context in the use cases because the Context is a specific class, and as such, a description of an implementation. "The context" without backticks refers to the concept implemented by the Context, which is what we're actually trying to capture.
There was a problem hiding this comment.
I pushed a change that replaced references to the Context with "the context" in the use cases markdown file and left the references to the Context in the appendix for now. Happy to discuss.
…n the pipeline (the Context with backticks).
…ecision making in downstream tasks. Make other assorted wording updates including removing references to removed use cases and standardizing actor names.
2 participants
I made some direct edits to the use cases doc and appendix. Please take a look and let me know what you think.