Hi Ray, This all sounds reasonable. For consistency, you should examine the Middleware use cases and adjust the courses of action accordingly. Thanks!
Jeff > From: Ray Plante <[EMAIL PROTECTED]> > Reply-To: Ray Plante <[EMAIL PROTECTED]>, LSST Data Management > <[email protected]> > Date: Tue, 21 Feb 2006 03:25:33 -0600 (CST) > To: LSST Data Management <[email protected]> > Subject: [LSST-data] Altering definition of Job [MiddleWG] > > Keywords: MiddleWG > > Hi UMLers, > > At our middleware videocon, I took on an action to press on some use cases > that elucidate how the Data Access Framework works its magic. A main > focus will be on the case of cross-talk correction. I am putting together > a problem statement will help scope what robust diagrams, for example, > need to be generated to illustrate this. I feel this needs to be put in > terms of the UML use cases and should perhaps include robustness diagrams > for related components that help support the context. While working my > way through this, I found the need to make (what I hope are) small > changes to the UML model. This message describes the first set of changes > which I just checked in. > > This set of changes appear in the Processing Framework Summary diagram in > the Framework package of the Domain Model. The main change is a shift in > the definition of a Job. Previously, this was defined to be something > that controls an instance of a Pipeline and scheduled by a Job Scheduler. > I have shifted the defintion of a Job to be the instantiation of a > *Processing Step*. The latter represents the unit of processing that is > actually scheduled and executed as a whole. The various processing steps > could be scheduled on different platforms (say, one step requires a > shared-memory platform). With this shift, I felt we now needed to show a > class that instantiates and manages a Pipeline as a whole, so I added a > "Pipeline Manager" class. > > To give you a sense of why I felt this necessary, I'll point out that the > model for parallelism for the cross-talk correction may be different that > that of the rest of the Calibration Pipeline. I wanted to allow, if it > turns out to be useful, the option of separating this correction into its > own processing step apart from the other stages of calibration (which > could require a shifting of data by the DAF). In this case, I feel we > need to show a little more clearly how processing steps are scheduled and > managed as individual entities. > > In summary, my changes were: > o shifted defintion of Job to be a scheduled instance of a Processing > Step. > o added Pipeline Manager class which contols a Pipeline and invokes a > Job Scheduler to shedule Jobs that carry out the Pipeline's work. > o added defintions (in the Notes Section) to key classes in the diagram > (attn: Jacek--including Provenance objects; please verify). > o rearrange visual layout accordingly. > > cheers, > Ray > > > _______________________________________________ > LSST-data mailing list > [email protected] > http://www.lsstmail.org/mailman/listinfo/lsst-data > _______________________________________________ LSST-data mailing list [email protected] http://www.lsstmail.org/mailman/listinfo/lsst-data
