Yes, I agree with that statement. Actually in the Rational OOA&D class you
wind up nuking most of the control classes as responsibilities fold into
entity classes. If you wind up with some responsibility that none of the
entity classes has the right to (its knowledge that they should not have)
then you ask yourself who should know how to do this. Generally I think
that the control class will either go away or turn into something more
substantial then just "Take Order Control". Before RUP I never wound up
with a class with a name like that.
Rusty
-----Original Message-----
From: Michael Hill [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 05, 2000 10:34 AM
To: 'Couball, James '; ''Williamson, Rusty' '
Cc: ''Rose Forum' '
Subject: RE: (ROSE) Separation of analysis and design (was:Use Case
Activi ty Diagram Location...)
I would be carefull when to use control classes. Use them if there are
business rules or some ordering when using multiple entity classes.
If there is not business rules or complex ordering of processing for
multiple entity classes then a control class my not be needed.
-----Original Message-----
From: Couball, James
To: 'Williamson, Rusty'
Cc: 'Rose Forum'
Sent: 12/4/00 4:12 PM
Subject: RE: (ROSE) Separation of analysis and design (was:Use Case Activi
ty Diagram Location...)
Rusty,
I find the analysis class stereotyes in RUP to be rather useful. They
serve
as place holders for things you should consider. Sometimes they
collapse
onto one another (ask for clarification if you don't understand this --
unless you closely follow RUP and/or have taken the OOAD with UML class
from
Rational you may not), but more often than not, they actually become
more
than one class in the design (particularly the UI classes).
You mention a worry about having entity classes be containers for data
and
control classes contain all the processing... I think this is mostly
what is
intended for analysis and is consistent with other methods I have used
in
the past. The control classes contain the functions to orchestrate (or
control) the use-case. Thus they contain the outwardly visible
behavior.
As you get to lower levels of abstraction (late analysis/early design),
responsibilities are then divided between the entity classes via
use-case
realizations.
Well, that's they way we do it. I am sure there are other correct ways.
Sincerely,
James.
-----Original Message-----
From: Williamson, Rusty [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 04, 2000 10:46 AM
To: Couball, James
Cc: 'Rose Forum'
Subject: RE: (ROSE) Separation of analysis and design (was:Use Case
Activi ty Diagram Location...)
James,
>Do you have guidelines for what can be in a class model in
analysis
vs. design?
I working on these now.
>Are they kept separate?
I think I'm going to keep analysis separate but in the use-case
realization
package.
>If so, are analysis artifacts kept up to date?
I believe that the analysis artifacts will go away, after all they serve
a
high level of abstraction and are used to determine design classes (some
analysis classes may become groups of classes, some operations,
properties,
entire subsystems or 3rd party products). In 'Version 1.1' (or the next
release) all of this will be in place. But... if they go away you lose
the
use-case realizations (the requirements trace). Does this matter? Will
you
need this downstream -- like when you plan the next release -- and if
you
use the existing use-cases to incorporate new functionality? Bottom
line,
I've decided to postpone this decision until I know more or see this
more
clearly.
>RUP seems to evolve analysis to design seamlessly without
saving
the analysis level of detail. Is that how you all see it?
Yes. The way I did it before RUP was to go right to design classes from
nouns in the requirements: a first cut; refine further by exploring
their
relationships and roles; refine further by defining responsibilities
with
CRC sessions. After this I pretty much merged with the RUP design
activities. The point is, the RUP method of doing analysis is new to
me.
The use of 'boundary', 'entity' and 'control' classes (model, view,
controller... sort of but not quite 'cause the abstraction level can
be...
anything)-- these analysis classes almost seems like some kind of method
dreamed up to 'kick start' non-OO designers. But then, that's what my
company has a lot of... and I'm not going to judge or knock the process
yet.
What makes me nervous is that using this method you can wind up just
putting
all data in 'entity' classes (private data with a public get and set for
each bit of data) and putting all processing in 'control' classes. This
is
exactly what procedural programmers do when they don't know any better
and
they try to do OOP! It looks like RUP try's to protect against this by
having you identify 'key abstractions' and then breaking them in to the
3
types of analysis classes. Then you map these to mechanisms. So an
different method that may work just fine. I guess we'll see.
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/
------------------------------------------------------------
-----Original Message-----
From: Couball, James [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 04, 2000 9:16 AM
To: 'Williamson, Rusty'; 'Charlie Mead'
Cc: 'Rose Forum'
Subject: RE: (ROSE) Separation of analysis and design (was:Use Case
Activi ty Diagram Location...)
Hello,
FWIW, I agree with Rational's decision to place analysis and design in
the
same workflow. The workflows don't indicate separation of concern, just
separation of work. It so happens that the two sometimes coincide.
In
many of the projects I have run, analysis and design are activities done
as
part of the same sequenece of activities.
I agree that it sometime proves useful to consider them separate
concerns
(but still in the same workflow).
I think we all agree (a good assumption?) to the high level defintion of
analysis and design: analysis is domain oriented while design is
solution
oriented. I am interested in hearing how others draw the distinction
between the _artifacts_ of analysis and design. Do you have guidelines
for
what can be in a class model in analysis vs. design? Are they kept
separate? If so, are analysis artifacts kept up to date?
RUP seems to evolve analysis to design seemlessly without saving the
analysis level of detail. Is that how you all see it?
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
*
*************************************************************************
