Rick, I think that you are running the risk of overcomplicating, if you don't try the simple alternatives first.
Use cases are goal-oriented hunks of system behaviour. You show the relationships between the use cases and the outside world with use case diagrams, and you show the interiors of the use cases with activity diagrams or state diagrams, depending mainly on whether your application is business or process automation. The original question was about what diagrams are typical in use case analysis, and this is a simple, powerful answer, implied, IMO, by the UML. -Eric "Martelli, Rick (EXP)" wrote: > > Hi Eric, > > Are you suggesting that I am complicating things by recommending that the > value of a particular diagram and the need for understanding the system > under development be your guide? > > Rick > > -----Original Message----- > From: Eric D. Tarkington [mailto:[EMAIL PROTECTED]] > Sent: September 26, 2002 1:31 AM > To: Martelli, Rick (EXP) > Subject: Re: (RUP) Diagrams in Use Cases > > I seem to be living in a simpler world than some: > > 1. Use cases are units of behaviour. > 2. Use case diagrams show the relationships between use cases, and > between actors and use cases. > 3. Activity diagrams are usually nature's perfect tool for showing the > sequential logic network that forms the interior of each use case in a > business application. > 4. State diagrams are usually perfect for showing the use case behaviour > in process control, or intensively real-time applications. > > You can add 1000 pages of subsections to these simple choices, but you > are not likely to get much real-world benefit if you don't use the > simplest pattern in the picture. > > IMO, the UML is baroque. Seeing past the excessive ornamentation is > really key to getting the potential benefit. > > -Eric > > "Martelli, Rick (EXP)" wrote: > > > > Hi Rakesh, > > > > To suggest that there are a typical set of diagrams for a Use Case is to > > imply that the value provided by a certain set of diagrams is consistent > > from project to project. This may be true. However, I find that the > value > > of a particular diagram, regardless of the type of diagram, has to be > > determined for each instance. > > > > The value of a diagram is based on its ability to help describe or > > understand the behaviour of the use case. Particularly in use cases where > > the behaviour is not well understood. It is at that point where the > > decision to select a particular type of diagram to assist in exploring > that > > behaviour is made. > > > > Best Regards, > > Rick Martelli > > Lockheed Martin Canada > > (613)599-3280 ext.3352 > > > > -----Original Message----- > > From: Rakesh Peter [mailto:[EMAIL PROTECTED]] > > Sent: September 24, 2002 3:08 PM > > To: [EMAIL PROTECTED] > > Subject: (RUP) Diagrams in Use Cases > > > > Can someone please explain to me what are the diagrams that are typically > > part of a Use Case? > > > > Depending on who i talk to I seem to be getting different answers from > > including class diagrams, sequence diagrams, activity diagrams etc. in a > Use > > > > Case. > > Can someone please help clear the confusion. Thanks. > > > > Regards, > > Rakesh ************************************************************************ * 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 *************************************************************************
