Alan:
It's fair enough to challenge my assumption that Sell a Unit includes behavior from Generate Sales Report. Suppose that the "report" has a real-time display, somewhat like a stock ticker. Click the Print button when you want to print a snapshot report. Other reports are also available via Generate Sales Report. Now you want immediate display of sales as they happen. Thanks for looking so closely at the question. Sell a Unit is behaving something like an actor with respect to Generate Sales Report, by triggering the Generate Sales Report behavior with an event or message (a sale). Generate Sales Report doesn't do everything that it might do in the presence of every possible message -- it only does what logic demands for the one incoming message. This definitely looks like an <<include>> to me, so I conclude that I don't need to use all of the behavior of an included use case. I don't envisage any common behavior between the two use cases as part of my system, so there's no reason to spawn a third use case. Reuse of operations wasn't in my question, anyway. -Eric [EMAIL PROTECTED] wrote: > > I have difficulty in seeing how Sell a Unit includes any behavior from > Generate Sales Report. In most systems, Sell a Unit would include adding > the data that the company feels is important to a persistent data store. A > use case like Generate Sales Report would extract data from the data store, > format it, and do whatever was necessary to create derived information. > > I suppose there could be some methods shared by both use cases, although > I'm not sure what behaviors these processes actually have in common. For > example, if a sales tax must be calculated I would assume that it has to be > calculated at the time the unit is sold. Rather than rederiving it for the > sales report, it should be taken from persistent data. > > I have used a <<communicates>> stereotype but only to show that a use case > provides data to an external system or actor and never as a link between > two use cases. > > Simply because you see an opportunity for reuse of operations you might > create in one of these use cases does not mean that there should be an > association between the use cases. There really needs to be a full set of > behavior from one that is also needed (always or occasionally) by the > other. I'm not clear on what level of behavior you see being shared > between these two use cases, but I think you make your use case analysis > more complicated than necessary if you head down the path you indicated. > > If there really are some "sub-behaviors that are shared by two use cases, I > suppose you could break them out into a third. However that seems too much > like functional decomposition, and I have a feeling that the resulting use > case would not truly be a use case. A better way to demonstrate shared > behaviors is to do an activity diagram for both of the use cases. The > shared sub-behaviors that you are concerned with will end up as activities > in both diagrams. I find that a good way to understand what is shared > across use cases is to do two or three layers of activity diagrams (the > second layer being and expansion of the activities in the first layer and > similarly for the third layer). The activities in the bottom layer > diagrams make good candidates for sequence diagrams as they contain much > less branching and iterative behavior. This gives a nice set of sequence > diagrams that can be used like components. Link the diagrams together > using Rose's capabilities and you can save a lot of time not having to > redraw 4 to 6 step sequences shared by multiple processes. > > ************************************************************************* > > PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > > ************************************************************************* ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Admin.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 * *************************************************************************
