Hi!
I'm not quite sure that I follow you completely but anyway here is my opinion... First of all I agree with you that white box realizations of a use case should not be put in the use case specification if not the customer explicitly would like this. Have you tried to use an analysis model, as described in RUP, with Boundary, Control and Entity Classes, which could serve a great abstraction between use case specs. and design? About the key mechanisms... It is true that a collaboration in UML (which use-case realization is a stereotype of) could represent the realization of a use case. But according to UML a Collaboration may represent any Classifier (including use case and class) or Operation. Thus, I would suggest that you break out common special requirements (analysis/design mechanisms in RUP) in separate Collaborations that describes them in more detail, for example Transaction Handling, Authorization, Persistence, Message Routing etc. These collaborations are likely to end up in subsystems in the lower layers of the architecture (by layers here I mean abstraction-based layering not tiers (or sometimes called responsibility-based layering)). In the standard rup layering this is the Middleware or System Software Layers. In ROSE it is possible to add notes in diagrams and make them 'clickable' to other diagrams by drag-and-dropping the diagram onto the note. In this way you may reference an analysis mechanism collaboration from all your other use case realizations. So, you'll end up we a couple of collaborations, some are use-realizations that represent use cases some are description of common behaviour such as Transactions, Authentication etc. The common collaborations are references from use case realizations. If you have RUP, see the following topics: Activity: Architectural Analysis#Identify Analysis Mechanisms Concepts: Analysis Mechanisms Concepts: Design and Implementation Mechanisms Activity: Use-Case Analysis Activity: Use-Case Design Activity: Subsystem Design Or look in The UP-Book, in the Design chapter. I don't if this is what you are looking for, but I hope that it helped :-) /Per Per Emanuelsson, Software Architect Jaczone AB [EMAIL PROTECTED] +46 (0)70-2693139 Kronborgsgrand 7 SE-164 46 KISTA www.jaczone.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Herve Blanc Sent: Thursday, April 04, 2002 10:31 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: (RUP) Use Cases, scenarios & realizations When looking at the realization of a use case, once you pass thru the interface layer, you might easily end up far from the use case step you were trying to realize in (a) sequence diagram(s). I use the annotation on the left side of the sequence diagram to keep a reference of the use case goals... at the begining, a copy / paste of the use case scenario... but since some of these sequence diagrams are too deep / far... I end up describing in a textual form what I am trying to achieve and then discover interfaces and objects required for the solution (I found a nice picture of what I am trying to describe here @ http://www.dcs.warwick.ac.uk/~ananda/lnotes/node100.html) So,we have this discussion in my group about what whether we should model those "internal interaction" scenarios in the use case view... and I argue that we should not as long as they are not interaction between the actors and the system and the stakeholders don't care how it's done There is value added describing what is happening inside the system but not forcefully for the users and stakeholders stand point, thus not in the use cases then. Most of these are key mechanisms, documenting your software gutts. Do you agree? If yes, do you have advices regarding how to organize the use case realizations and link those "internal interaction" scenarios to the use cases that initiated the sequence? We may end up with 10-15 sequence diagrams for some use case realizations... Should each of the sequence diagram be associated 1 use case realization and many use case realizations associated to 1 use case? Or should we have those 10-15 diagrams connected to this 1 use case realizations? Should these diagrams belong in the use case realization package or should they belong to the layer & partition implementing most of it? Well, I am not sure how/where in rose should those "execution path thru the system" scenarios be modeled and I surelly would appreciate inputs on the topic, Thanks, Herve. **************************************************************************** ***** * RUP Forum is a public venue for discussions about the * Rational Unified Process (RUP). * * For RUP support materials, process Plug-Ins, tutorials, whitepapers, * a biweekly column, Rational University training courses, and more, * please visit the Rational Developer Network (available to Rational * customers) at: http://www.rational.net. * * For technical support of RUP, RPW, Rose or any other Rational * product, please visit: http://www.rational.com/support * * For other discussion groups, such as Rose and UML, please * sign up at: http://www.rational.com/support/usergroups/index.jsp * * To reply to a posting, please "Reply to all" or send * To: [EMAIL PROTECTED] * * Admin.Subscription Requests: [EMAIL PROTECTED] * * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send an email: * * To: [EMAIL PROTECTED] * Subject:<BLANK> * Body: unsubscribe rup_forum * **************************************************************************** ************************************************************************ * 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 *************************************************************************
