James,
Could you give us some feedback on this book? It's not one I'm familiar
with, and a quick browse on Amazon shows it's not _too_ expensive.
Intriguingly the title mentions the Unified Process rather than the Rational
Unified Process. Have the two significantly diverged? Are there in fact
still 2 processes, or has the UP ceased to be since its adoption and
extension by Rational? Can anyone else shed any light on this.
Sorry if this is straying a bit off the list topic here but hopefully it's
of interest to the majority.
Phil Bowker
> -----Original Message-----
> From: Couball, James [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 04, 2000 6:19 PM
> To: 'Williamson, Rusty'; 'Charlie Mead'
> Cc: 'Rose Forum'
> Subject: RE: (ROSE) Use Case Activity Diagram Location...
>
>
>
> Rusty,
>
> I am about a quarter of the way though a book titled: "The
> Unified Process
> for Practitioners: Object Oriented Design, UML, and Java". I
> thought you
> might be interested in this book goes into the detail of the
> analysis and
> design workflows of RUP.
>
> Interested to hear what others think about this book.
>
> Sincerely,
> James.
>
> -----Original Message-----
> From: Williamson, Rusty [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 01, 2000 3:35 PM
> To: 'Charlie Mead'; Williamson, Rusty
> Cc: Couball, James; 'Rose Forum'
> Subject: RE: (ROSE) Use Case Activity Diagram Location...
>
>
>
> Hi Charlie,
>
> Regarding 'Use Case Activity Diagram Location' -- the answer
> was never in
> doubt in my mind (which is always a sure sign to seek
> confirmation when it
> comes to UML!!) but our RUP instructor made some statements
> that confused
> the issue and others in my organization were in danger of
> setting off in a
> direction I felt was... not the best. You are right in line with my
> thinking on this and so, it seems, is Rational. My rule on
> the use-case
> model has always been "if its an 'external view' of 'what'
> the system does
> it goes in the use-case model" (it looks like RUP puts
> storyboards in the
> analysis model or use-case realization area so this is now kind of an
> exception). Anyway at the end of this email I've included an
> email from
> Rational support on this and other matters that were being questioned.
>
> Regarding 'blurred... by combining Analysis and Design': I'm
> willing to give
> it a chance. The decision was made to try to follow RUP 'as
> is' as much as
> possible in the elements we use (that is we are forgoing
> elements we don't
> feel we need). Your question is timely for me as I am at
> this moment trying
> to figure out how to get from 'use-case realization' analysis
> classes to
> 'design model' design classes. Pretty much I'm just doing
> the analysis
> model (and story boards) under 'use-case realizations'.
> Use-case model to
> 'use-case realization' is cleanly represented by a stereotyped
> <<realization>> dependency (as with include/extend, in Rose you use an
> association... unbelievable!) and all of your analysis
> diagrams go 'under'
> this realization. Now for trace-ability between this and
> 'design' we should
> do the 'many-to-many' analysis class to 'design class or
> subsystem or method
> or whatever' using the trace dependency... but where exactly?
> Anyway, I did
> like the analysis model (although I was really brought up on
> a different
> approach using CRC) but I think this will serve.
>
> Regards,
> Rusty
> ------------------------------------------------------------
> Rusty Williamson
> > Sr. Systems Architect
> GERS Retail Systems
> http://www.gers.com/
> The Object Workshop
> http://home.san.rr.com/williamson/
> Home Page
> http://www.znet.com/~rusty/
> ------------------------------------------------------------
>
> ------------------------------------------------------------
> From Rational Support
> ------------------------------------------------------------
> Hi Rusty,
>
> I got the following comments from one of the RUP developers:
>
>
> > ------------------------------
> > Question 1: Regarding the reply from 'one of the Rational University
> > trainers in Europe', he says:
> > >Without claiming this to be the only way to do things I
> will provide my
> > view
> > >of things.
> > Isn't there an 'official' RUP way of doing things?
> Jacobson, Booch and
> > Rumbaugh's "The Unified Software Development Process" 1999
> Addison-Wesley
> > states this in no uncertain terms.
>
> The RUP is not quite as rigid as the your question makes it
> sound. For any
> project, there is a range of appropriate solutions and
> formality of process.
> The choice of how formal to be, and what parts of the process
> to use, is
> driven by risk and specific observed process-related problems. This
> configuration of the process is, in fact, a key benefit of the RUP.
>
> So while RUP does provide a set of best practices, the choice
> of which best
> practices to apply will vary based on the situation. The
> instructor may not
> have made this as clear as it should have been.
>
> > Question 2: Regarding the reply from 'one of the Rational University
> > trainers in Europe', he says:
> > >In the UC-view you can create an activity diagram to describe the
> > >normal flow and the alternative flows...
> > Trying to answer from the view point of the RUP -- are
> statechart and
> > interaction diagrams still used in this manner? I say
> 'still' due to the
> > following section from Jacobson, Booch and Rumbaugh's "The
> > Unified Software
> > Development Process" 1999 Addison-Wesley, page 159:
> > "
> > Sometimes however, as in complex real-time systems, the use cases
> > may be so
> > complex that it becomes necessary to use a more structured
> description
> > technique. The interaction between the actors and the use
> cases may, for
> > example, go through so many states and alternative
> transitions that it is
> > almost impossible to keep a textual use-case description
> > consistent. It may
> > then be useful to use a visual modeling technique to describe the
> > use cases.
> > Such techniques can help the system analyst to better
> understand the use
> > cases:
> >
> > * UML statechart diagrams can be used to describe the
> states of the
> > use case and the transitions between those states; see Figure 7. 16.
> > * Activity diagrams can be used to describe the
> transitions between
> > states in more detail as sequence of actions. Activity
> diagrams can be
> > described as a generalized form of SDL state transition diagrams
> > [15], which
> > is a well-proven technique used in telecommunications.
> > * Interaction diagrams can be used to describe how an
> instance of a
> > use case interacts with an instance of an actor. The
> interaction diagram
> > then shows the use case and the participating actor (or actors).
> > "
>
> This is a correct statement and the RUP needs to be more
> precise in stating
> when and how different diagramming techniques can be applied.
> The book
> provides a good introduction to how and when these techniques
> could be used.
>
> > Question 3: Regarding the reply from 'one of the Rational University
> > trainers in Europe', he says:
> > >In the UC-view you can create an activity diagram to describe the
> > >normal flow and the alternative flows (partly replacing
> the need for a
> > >textual uc-description)
> > I'm not sure I would ever use an activity diagram (or sequence or
> > interaction diagram) to 'partly replace' the textual
> uc-description, but
> > rather to explore, workout and display complex use case
> flows. So that I
> > could understand and know that we (the end user and myself) were
> > on the same
> > page with what the system should do under multiple decisions and
> > circumstances. Sending an example would be difficult but
> I'm sure you
> > encountered these type of use cases. Also the above quote from
> > Jabcobson's
> > book alludes to this.
>
> Agreed.
>
> > Question 4:
> > Please confirm for me (actually for a co-worker) that you
> would not see
> > analysis classes anywhere the use-case view.
>
> That is correct; analysis classes would not appear in a use
> case view; they
> are related to use case realizations but these are part of
> the logical view.
>
> Best regards,
> Sara
> ===============================
> Sara Lerman
> RUP/RPW/SoDA Technical Support Engineer
> ===============================
> ------------------------------------------------------------
> ------------------------------------------------------------
>
>
> -----Original Message-----
> From: Charlie Mead [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 01, 2000 7:12 AM
> To: Williamson, Rusty
> Cc: 'Couball, James'; 'Rose Forum'
> Subject: RE: (ROSE) Use Case Activity Diagram Location...
>
>
>
>
>
> It seems to me that the real question is "what is the diagram
> trying to
> visualize?' -- and when you use an AD (with or without Swim
> Lanes -- I very
> much
> prefer the former) to visualize the flow and interaction
> between Actors and
> the
> System in a Use Case, you are looking at the system "from the
> outside,"
> which is
> what the UC view is supposed to do....the fact that you've
> used an AD is
> immaterial...the fact that you've viewed the system from
> outside is the
> critical
> fact....
>
> On a related subject: I do think that Rational and RUP have
> blurred/confused
> things a bit by combining the Unified Process's view that
> there are two
> distinct
> workflows -- Analysis and Design -- into one single workflow
> (Analysis and
> Design).....I have found considerable value in formalizing
> the Analysis
> workflow
> via UC realizations that are implementation independent and
> look basically
> like
> Jacobson's Robustness Analsysis stereotypes (and RUP's
> Analysis classes)
> placed
> in Collaboration (or responsibility-based Sequence) diagrams....the
> advantage of
> going through a round of UC realization a the "concept-not-class" and
> "responsibility-not-operation/message" level is that it
>
> a) helps you discover things about the UC you may have overlooked; and
> b) firmly established a tracability link into the UC
> realizations at the
> design
> level.
>
> Also, I have found that the ability to produce
> implementation-independent UC
> realizations (vs implementation-specific design-level ones)
> may not lie with
> the
> same person....System Analysts are, in general, much more
> willing to be (at
> least for the moment) blissfully ignorant of implementation
> details while
> simply
> modeling responsibility-based collaborations between
> instances of analysis
> model
> concepts rather than design-level classes .....designers, on
> the other hand,
> tend to want to get immediately to the class and message level in the
> realization....the Unified Process argues, I think, very
> convincinly for
> having
> a UC Realization--Analysis activity which is separate from the UC
> Realization--Design activity.....I wonder if Rational
> combined the two UP
> Workflows in large part because of their essentially identical tooling
> requirements....but I don't know that.....
>
> In the RUP class I took, the instructor said that Rational
> believes that
> developers/designers can gather requirements, build Analysis models as
> needed,
> and move to design and that therefore the workflow Analysis and Design
> should be
> considered as a single workflow....maybe that's true....but
> I've found it
> hard
> to keep good designers at an implementation-independent level
> for too long.
> --
> and also found that their work is made much easier and
> traceable (i.e. their
> implementation-specific compromises much easier to evaluate
> and potentially
> negotiate with customer requimenets) in the presence of formal UC
> Realizations
> at the Analysis level....
>
> charlie
>
>
> **************************************************************
> **********
> * 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/products/rose/usergroups/rose_forum.jtmpl
> * Other Requests: [EMAIL PROTECTED]
> *
> * To unsubscribe from the list, please send email
> *
> * To: [EMAIL PROTECTED]
> * Subject:<BLANK>
> * Body: unsubscribe rose_forum
> *
> **************************************************************
> ***********
> **************************************************************
> **********
> * 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/products/rose/usergroups/rose_forum.jtmpl
> * Other Requests: [EMAIL PROTECTED]
> *
> * To unsubscribe from the list, please send email
> *
> * To: [EMAIL PROTECTED]
> * Subject:<BLANK>
> * Body: unsubscribe rose_forum
> *
> **************************************************************
> ***********
> **************************************************************
> **********
> * 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/products/rose/usergroups/rose_forum.jtmpl
> * Other Requests: [EMAIL PROTECTED]
> *
> * To unsubscribe from the list, please send email
> *
> * To: [EMAIL PROTECTED]
> * Subject:<BLANK>
> * Body: unsubscribe rose_forum
> *
> **************************************************************
> ***********
>
************************************************************************
* 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/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
