Subject: RE: Model review time!
Yuta, I am now just getting to the detail of you email and you raise very good points. My comments are below in <Scott></Scott> tags. thank you very much for your review. Scott -----Original Message----- From: Yutaka Yoshida [mailto:Yutaka.Yoshida@eng.sun.com] Sent: Thursday, March 16, 2000 2:16 PM To: firstname.lastname@example.org Subject: Re: Model review time! Scott, thanks a lot for this. > From: "Nieman, Scott" <Scott.Nieman@NorstanConsulting.com> > > 1) determining if people can actually view via the web the model I had to download the zipped one because the online version had an applet which my browser didn't allow to run due to a security reason. I don't know what's wrong with it, though. > 2) helping review and complete the model. > > Authentication Use Case > Authentication Workflow Activity Diagram + I like the following Terry's idea, but I'm not sure what kind of 'software screening' Scott and Terry are thinking of. || "Submit anything in any form" could be made to apply to related || data for something in one of the formats the registry is set up to || handle. Then if the submission's "principal registered item" (see || attached) is in one of those formats the software check would pass it. <Scott>The point of this was that the ebXML Business Process project team was going to give us a checklist of required items in a submission, and the software could verify if the items in the checklist were present. This is their definition of the "metamodel". So if the submission was in a format that we could analysis (e.g., XMI - if that works for us), we could parse it, and verify its integrity.</Scott> + We might want to separate the authentication process, or the authentication process for SO registering could be an inheritance of the regular authentication. <Scott>This was addressed in a separate thread. Packages have been added to the model referencing ebXML Architecture Security Services and ebXML Architecture Messaging Services.</Scott> + The actor "ebXML-Compliant Business Application" says "may interface with a repository...". Is it not suppose to interface with registry? <Scott>Corrected. Thanks.</Scott> > > Register Submitting Organization Workflow + Probably, SO needs to view the status of registration. + Needs a start point for RA. The current start could be used for both SO and RA, but it needs another diverging point in that case. Maybe all RAs' actions in this diagram can be put into "Authorize Submitting Organization" Workflow because when I think about the sequence diagram and the collaboration diagram, SO registering workflow and RA authentication workflow could be ubiquitous. <Scott>A couple points here: 1) I created a <<Logical>> Registration package in the Domain Package Diagram that now has a Registration Use Case diagram. The <<Logical>> stereotype will reflect the human interface and the <<Physical>> stereotype will represent the workflow engine or basically the component API. Therefore, the use cases in the <<Logical>> will <<use>> the <<Physical>> use cases. The <<Physical>> implementation of the start point for the RA could be to move the registratoin request to the RA inbox and that would happen in the background. The <<Logical>> implementation would have the RA look at his inbox to view etc. I do not have a problem changing the <<Logical>> stereotype to <<GUI>> or something more clear, and likewise with <<Physical>> to <<API>>. 2)The N090 methodology is similar to the RosettaNet UML profile in that the "actions" on an Activity in an activity diagram will be an operation in the component interface, possibly in a one-to-one relationship. A operation on a component interface is realized by a collaboration of objects. We first represent this as a number of sequence diagrams; one main path and a number of exception paths. We can then combine the sequence diagrams into one collaboration diagram which represents the realization of that operation with traceability back to the activity in the activity diagram. To model the activity diagram as a sequence diagram itself would be very cluttered and is not encouraged. </Scott> General question: Most of the workflows do not look like business-specific procedures, but do like regular flows. Do we really need to describe non- business specific flows in detail? Or, are we trying to figure out what and where the critical point is to satisfy business requirements? <Scott> Correct. The workflows that we have today are software specific, and less on the GUI. As discussed above, the needs to be separation between the two to show the business-specific process, and the physical realization. We need both perspectives. </Scott> yuta
eList eXpress LLC