Jie, You should not use include or extend relationships to model the sequence in which use cases are invoked. The include relationship is to be used when you would like to reuse the behavior described in one use case when modeling another. If the included behavior starts with some user input, the base use case is to be dependent on the result of performing the included use case. Otherwise, there is no need of the relationship; the inclusion use case is simply another use case performed in parallel. If the inclusion use case does not start with some user input, it is quite obvious that you need the relationship from the base use case to the inclusion use case. Otherwise, the included behavior will not be performed when instantiating the base use case.
Similar for the extend relationship. If you do not have the user input at the start of the extension use case, you need the relationship. If you do have some user input at the beginning of the extension use case, the extension behavior is to use or modify some values that exist in the base use case. Otherwise, it is just another use case performed in parallel with the base use case and there is no need of the relationship. Then, it is also a matter of which use case is to be dependent on the other. In your example, I would say that UC-Maintain Customer ought to include UC-Search Customer, since the latter has nothing to do with maintaining the customer information (but that is my interpretation of your example). However, if the user would like to use the search function to find the information about the customer he or she is to update, the UC-Maintain Customer needs to have an include to UC-Search Customer. If there is no relationship, it will not be possible to use the information found when performing the behavior of UC-Search Customer directly in UC-Maintain Customer. Without the relationship there will be two separate use-case instances, and the information retrieved in one of them, such as the name of the customer, must be re-entered by the actor into the other. With an extend from the UC-Maintain Customer to UC-Search Customer, you will be able to modify the information found in the latter use case. If the relationship is removed, the instance of the UC-Maintain Customer will not have access to the information retrieved by the instance of the UC-Search Customer. The actor has re-enter it. Hence, if the information retrieved, calculated etc. in one of the use case is to be used in another, parallel use case, there must be a relationship between the use cases (and hence just one use-case instance). Otherwise, an actor must receive the information from the first use case and re-enter it into the second. Which relationship to choose depends on which use case is to be dependent on the other. Gunnar Gunnar �vergaard VP Knowledge Development Jaczone AB Kronborgsgrand 7 164 46 Stockholm, Sweden [EMAIL PROTECTED] www.jaczone.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:owner-rup_forum@;Rational.Com]On Behalf Of Jie Zhao Sent: den 11 oktober 2002 13:21 To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: (RUP) Use Case Relationship vs User Interface Navigation Path When using <<include>> or <<extend>> relationships between use cases, somehow it expresses the sequence of the use cases initiated. For example, UC-Maintain Customer can be extended by UC-Search Customer if the user wants to update an existing customer details, equally, UC-Search Customer could be extended by UC-Maintain Customer if at the end of customer search the user wants to edit the customer's info. Now we end up with <<extend>> relationship either from UC-Maintain Customer to UC-Search Customer or the other direction. Clearly there is a question regarding if it is appropriate to use the <<extend>> relationship above. What I would prefer is not to use <<extend>> relationship at all and create a User Experience diagram to model the navigation path. Even further, I would like to have no any <<include>> or <<extend>> relationship between use cases that can be activated directly by users. Any thought/best practice about this? Thanks Jie **************************************************************************** ***** * 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 *************************************************************************
