Hi Jie,
I tend to agree with Scott that you should consider a more business focused point of view - Order Taker/Order Processor. In my opinion, you are making design assumptions that limit and obfuscate the pure business issues. However, you DO need design to deliver this business. The subsystems and the protocol (xml file) are sound options. Let me assume that you have done the business modeling that Scott has suggested, you can now use the design that you presented. The question now becomes how should the functionality of the two subsystems be represented. It is OK to describe business use cases in terms of subsystem use cases, i.e. distribute the functionality to the subsystems. If you do this then one subsystem is responsible for the use case but it delegates large portions of the behaviour to the other. This is good because it formalizes the relationship between the subsystems. (Better than, we just leave this file there and he will likely find it). Now that said, you ask should the the mainframe subsystem be an actor for the upload use case. We find the answer simply by asking - Who provokes whom? Actors provoke systems to execute a use case. Before you can answer, we'll ask two more questions - What is the Business Level use case, the one that Scott mentioned, the one that delivers real value to a real business actor? and Who (which subsystem) initially accepts responsibility for that use case? You may find that the "Upload Order UC" is really only the fulfillment of some request initially made by the Desktop subsystem, in which case, the Upload is really only a response to a previous request (maybe made hours before). If this is the case, then the desktop is the actor to a mainframe use case. One last note, you should, nay must, manage the dependencies between the subsystem. Do not create cyclic dependencies between the subsystem. Don't do it. Really. That means that if the desktop is an actor for a mainframe usecase, then never can the mainframe be an actor for a desktop use case. Never. Ever. If you really think that you need such a thing, then you must fission the subsystems so that it is clear who is the server (performs the use case) and who is the client (actor). Murray Cantor wrote a good book describing the different levels of use cases called "Object-Oriented Project management with UML" (wiley) John Lakos wrote a really good book on dependency management with C++, but the concepts apply to all software. See "Large-Scale C++ Software Design" by AWL. Jie Zhao wrote: > Hi, > > Scenario: There are two susbsystems, say, Desktop Subsystem and Mainframe > Subsystem. A number of use cases have been identified for each subsystem, > such as, UC Maintain Order, Upload Order for Desktop Subsystem, Process > Order UC for Mainframe Subsystem. For Upload Order UC, the Desktop subsystem > will eventually save an XML file on the network drive, which the Process > Order UC in the Mainframe Subsystem can pick up to do an overnight batch > processing. So clearly the interface betweem the two subsystems is the XML > file. > > Question: When creating Desktop subsystem use case model, should Mainframe > Subsytem be an actor that is related to the Upload Order UC? > > > Any thoughts are really appreciated! > > Jie > > ************************************************************************ > * Rose Forum is a public venue for ideas and discussions. > * For technical support, visit http://www.rational.com/support > * > * Post or Reply to: [EMAIL PROTECTED] > * Subscription Requests: [EMAIL PROTECTED] > * Archive of messages: > * http://www.rational.com/support/usergroups/rose/rose_forum.jsp > * Other Requests: [EMAIL PROTECTED] > * > * To unsubscribe from the list, please send email > * To: [EMAIL PROTECTED] > * Subject: <BLANK> > * Body: unsubscribe rose_forum > ************************************************************************* > > -- Neil Pitman [EMAIL PROTECTED] +1.514.863.5465 ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Post or Reply to: [EMAIL PROTECTED] * Subscription Requests: [EMAIL PROTECTED] * Archive of messages: * http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum *************************************************************************
