Anthony,
These are not just my comments. I have been practicing, teaching and
consulting UML, OMT, OO for many years, and people do have the need for
clear process descriptions.
E.g. I explain in such a process, the need to create summary diagrams (this
is a way to deal with complexity management: what you see is the whole
truth, but only that part that you wish to see now). Or I explain that
arrows in sequence diagrams and state transition diagrams should almost
always relate to operations of your classes.
And then I have to start explaining about UML and why UML tools do not
support these aspects as straight forward as can be expected. And the reason
for this lack of support is clear: the tools support the notation instead of
the process.
Look at the majority of books about UML. Far too much notation. 80% of the
books start off with the class diagram. (just as a test, I take the UML
Reference Manual from the amigos off the shelf, and it starts with the class
diagram as well). The activity diagram is invented, and at once, books are
updated to mention the activity diagrams as well. A diagram needs to have a
clear purpose in a process.
I agree that (some) people tend to feel restricted when having to operate in
a process "framework". (it sounds a bit like a prison). That is why I used
the term "process ingredients" in an earlier message. A tool supports
process ingredients. It does not necessarily force you to do something. But
you have a point. A tool needs to find a balance between flexibility and
process guidance.
And I am sure that, in the courses you give, you have felt the same needs,
and you do give the guidance people are looking for. All your course
material is based on RUP. I just try to explain how people perceive RUP.
I restricted my comments to modeling activities. Of course, there is also
project management, configuration management, all types of testing, etc...
And RUP does provide guidance here. But the support is not very detailed in
my opinion. RUP is broad, and very generic. Being broad is never bad. But
the modeling activity is a crucial part. And I believe that this modeling
activity could be supported in a more detailed way. A lot of the RUP
information is not dependent on UML. And this aspect could be improved. But
I am also convinced that going further in this direction, leads to
additional functions that you would expect to be supported in the UML tool.
Because process support is more than a book.
And thank you for picking up the discussion as well.
Johan
=========================================
Johan Galle
mailto:[EMAIL PROTECTED]
HOORA, the practical approach to UML: http://www.hoora.org
=========================================
>
> Hi Johan
>
> These are useful comments. I believe that we do provide the
> answers to your
> questions in RUP - the debate would be are they easy enough
> to find for new
> users. I have taught a lot of classes in the past for
> Rational where we do
> give the guidance you feel is important - and our material is
> all based on
> RUP.
>
> I would also like to extend the discussion - as modeling and
> UML are not the
> only thing to worry about - what about requirements management as
> text/documents/plans as well as UML, testing, project
> planning, etc, etc -
> this is also very important and what the Rational toolset
> does worry about
> (and RUP gives guidance on).
>
> Sometimes, project teams resist stronger process enforcement
> as they feel it
> restricts them. I believe we offer the ability to have a
> good range of
> process enforcement, from strict to more flexible - but we can always
> improve!
>
> I think this is a good discussion to have - perhaps we should
> move it to the
> rup_forum as this is wider than just modeling tools.
>
> Thanks for your contributions to the forum - this is an interesting
> discussion.
>
> regards
>
> anthony
>
> > Yes, a tool should give stronger process guidance. That is
> > precisely my
> > point.
> > Take some examples.
> >
> > Take all the Rose and RUP information. And let us see if we
> get enough
> > guidance.
> > How long does it take to find an answer to questions that
> > should be trivial,
> > such as:
> > - what should I start with? Class diagrams?
> > - how do I go from requirements to use cases to class diagrams?
> > - how do I use packages to structure my model?
> > - what is the relationship between the business object model,
> > the analysis
> > model and the design model?
> > - what is the relationship between the class diagram and the
> > interaction
> > diagram? Does one influence the other?
> > - ...
> > I do not claim that these are yes-no questions. I do not
> > claim that the
> > answer is not available. But teams need simplified
> > presentations and then
> > you can start explaining that there are variations.
> > (And these are only pretty high-level questions. If we would
> > go to a more
> > detailed level, answers are even harder to find, e.g. are
> > there are any
> > rules or guidelines about connecting model elements in
> > different packages)
> >
> > Another example. A tool needs to built based on the process
> > used and not
> > just on the notation. Why is it so hard in Rose to link the state
> > transitions in a state transition diagram to operations of
> > the class you are
> > modeling (I agree, not the only possibility, but still very
> > probable)?
> > My answer: because the goal is (was) to support UML instead
> > of supporting
> > the modeling activity.
> >
************************************************************************
* 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
*
*************************************************************************
