|
Hi
David,
I'd
like to disagree with your comments on RUP and UI design. I've been
involved as a consultant with three RUP projects, all of which had
a significant UI component, two of which were very large, one small.
Firstly,
there are factual errors, omissions and seemingly deliberate misleading
statements:
* The OMG does not proffer the Unified Development Process as
a standard. The RUP meta-model is being put forward as a possibly
standard way of describing processes - the content of the process
itself is not.
* A more elaborate, detailed process does not mean a more proprietary
process
* Rational has not 'recently elaborated RUP' to include the boundary
control entity classes. This technique has been around in Objectory;
i.e. the precursor to RUP.
* Stating that UI Design is part of the requirements phase does
not make it a 'Poor Cousin'. RUP is obviously trying to get UI
Design involved up front, to avoid the issue with BA's or SA's
writing the requirements in isolation.
Second,
Use Cases as proposed by RUP are *very* user centric, not system
centric (hence the name!). Specifically, the RUP states that internal
actions that the system performs are not part of the use case, but
instead provide an observable result to *an actor*. The RUP puts
forward techniques such as storyboarding to complement use cases
to help UI design. Again, it also includes the role of UI Designer
as part of the requirements workflow to help ensure that UI design
is not forgotten.
The
role is important in UI, as your Constantine quote points out. However,
this does not mean that actors are any different to a role! Constantine
must never have read the UML definition of an actor; refer to the
UML Reference Guide, page 144: "Each actor defines a set of roles
that users of a system may assume when interacting with the system"
This definition is hardly in conflict.
Reading
RUP it is apparent that the Control class is never intended to include
business logic for modifying entity data - it is purely a co-ordination
device. This *is* good OO design, since it separates out different
responsibilities - that of co-ordination of events and data manipulation.
You yourself have noticed that Sun have followed this principle
with Session and Entity Enterprise Java beans, so Rational is certainly
not alone here. Are you therefore suggesting that all the EJB systems
are not scalable???
RUP
does not suggest that Control analysis classes end up as a single
coded class. It states the very opposite: that when you move to
design you have to take into account constraints other than behaviour,
which usually always leads to creating many design level classes
from individual analysis classes - hence the reuse problems you
refer to in reality never eventuate.
In
your example with the 4 use cases that include a login use case,
you state: "But must we also not instanciate a <> class
for UseCase1?"
The
answer is that the control class would be instantiated for use case
1, but this occurs when the user starts this use case, which in
turn would start the login use case, if required. RUP states this
rather clearly. Hence multiple control logic for a large number
of use cases is not started simulataneously. Furthermore, a large
system will never have 400 use cases, unless the author of the use
cases has misunderstood the phrase 'a use case provides observable
value to an actor'. The largest system I've seen (a national social
security system of systems) had around 180 use cases. A public transport
ticketing system for trains, buses etc had around 50.
I
look forward to your answer!
Best
Wishes
George Davis
uidesign.net
reply...
I'd
like to disagree with your comments on RUP and UI design. I've been
involved as a consultant with three RUP projects, all of which had
a significant UI component, two of which were very large, one small.
Firstly, there are factual errors, omissions and seemingly deliberate
misleading statements:
* The OMG does not proffer the Unified Development Process as
a standard. The RUP meta-model is being put forward as a possibly
standard way of describing processes - the content of the process
itself is not.
This
was incorrectly reported to me by a Rational Consultant who was
poorly informed. I have made the correction to the article. Thanks
for pointing this out.
* A more elaborate, detailed process does not mean a more proprietary
process
* Rational has not 'recently elaborated RUP' to include the boundary
control entity classes. This technique has been around in Objectory;
i.e. the precursor to RUP.
This
is also strictly true. However, Rational Consultants are actively
teaching the technique as part of the elaboration process. As has
been pointed out to me by Philippe Krutchen, himself, this does
not make it part of RUP. RUP does not define such detail, that is
left to the implementation. However, the implementation being taught
by Rational does include them. Decide for yourself whether BCE is
"in" or "out" of the RUP.
* Stating that UI Design is part of the requirements phase does
not make it a 'Poor Cousin'. RUP is obviously trying to get UI
Design involved up front, to avoid the issue with BA's or SA's
writing the requirements in isolation.
RUP
offers no notation for UI design. It also offers no advice on how
to undertake UI design as a design process, or how to do analysis
for it. It simply states that UI is done as part of the requirements
phase. In practical teaching all UI classes are Boundary classes.
Not very helpful.
Second, Use Cases as proposed by RUP are *very* user centric, not
system centric (hence the name!).
I
think, as Constantine also pointed out, this was Jacobson's original
intention. This intention has been lost. Viz, the quotes I lifted
from Kruchten's latest book on the topic.
Larry recently shared a conference panel chair with Philippe in
Sydney Australia about 3 weeks ago. They had a very similar conversation.
The reality is, that RUP is NOT about users - it's all about the
System.
Specifically, the RUP states that internal actions that the system
performs are not part of the use case, but instead provide an observable
result to *an actor*.
The
problem with this is that anything can be an Actor. Including any
other class, sub-system, component, interface, legacy system and
so forth.
The RUP puts forward techniques such as storyboarding to complement
use cases to help UI design.
Without
explanation of how you might use them or how you map them to/from
Use Cases.
Again, it also includes the role of UI Designer as part of the requirements
workflow to help ensure that UI design is not forgotten.
This
is a band aid when a complete rethink was required. As Constantine
points out - there is no UI analysis or design process in RUP.
Sure everyone doing RUP needs to do UI analysis and design, but
the process doesn't specificy how it is done or how you map it into
the process. The only reasonable attempt at solving this problem
was presented by Deborah Mayhew in her book The Usability Engineering
Lifecycle, and in any event she based her technique on OOSE (the
forerunner of Objectory).
The
role is important in UI, as your Constantine quote points out. However,
this does not mean that actors are any different to a role!
What
Larry is after is a separation from the idea of an Actor as a collection
of Roles from the altogether different idea of an Actor as another
system, sub-system, component, class, interface.
Constantine must never have read the UML definition of an actor;
refer to the UML Reference Guide, page 144: "Each actor defines
a set of roles that users of a system may assume when interacting
with the system" This definition is hardly in conflict.
I
believe that I quoted that also. I also believe that Larry is well
aware. Remember Larry is the guy who invented Structured Analysis
and Design in the 1970s. He ranks in the top 5 IT people of all
time alongside Knuth and Yourdon.
Reading RUP it is apparent that the Control class is never intended
to include business logic for modifying entity data - it is purely
a co-ordination device.
I
believe that you are puting the correct interpretation on a Controller.
A Jacobson "control" class however, is a flow of control
for the application where the application and business logic are
tightly coupled. From your description, you believe as I do that
the state of the presentation layer (Views and Controllers) must
be separated from the state of the business system. This is not
the Jacobson approach.
This
*is* good OO design, since it separates out different responsibilities
- that of co-ordination of events and data manipulation.
On
the contrary - it breaks encapsulation. Basically, it is old fashioned
procedural programming wrapped in object technology. You could be
doing it in Pascal.
This should be no surprise. Use Cases and Use Case modeling / analysis
are procedures and procedural decomposition. Don Firesmith pointed
this out in a well publicised paper as early as 1995. Ben Kovitz
is also a published author who has made similar observations.
You yourself have noticed that Sun have followed this principle
with Session and Entity Enterprise Java beans, so Rational is certainly
not alone here. Are you therefore suggesting that all the EJB systems
are not scalable???
The
real issue with EJBs was the lack of re-entrancy in the 1.0 specification.
This is partially fixed in the 1.1 specification. As a result of
no re-entrancy and the heavy cost of a remote call over http, proper
business modeling in Entity Beans was not possible. The logical
flow of a business method had to be pushed up to a Session Bean,
which made the BCE modeling method empathetic with the EJB 1.0 specification.
It is now possible to do proper business layer modeling in EJB 1.1
particularly with Application Servers such as Weblogic which will
not invoke a remote call over http between Entity Beans running
in the same box.
RUP does not suggest that Control analysis classes end up as a single
coded class.
Rational
are very much advocating that and teaching in their consultancy
classes. Jacobson was also advocating this back in 1994 when he
suggested that you code the use case as a class.
It states the very opposite: that when you move to design you have
to take into account constraints other than behaviour, which usually
always leads to creating many design level classes from individual
analysis classes - hence the reuse problems you refer to in reality
never eventuate.
I
wouldn't agree with this. The reality is that the analysis and decomposition
method is procedural. If you do good quality procedural analysis
then you may get reasonable re-use in a single application but you
have tightly coupled application flow with business logic.
In fact in defence of RUP it is often claimed that "Reuse across
applications never really happens anyway". This is fundamentally
not the case!
How
many applications have you seen where there was a sister Administrators
Application which reused the same data? In the web world where we
have HTML, cHTML, HDML, ML and VXML versions of web sites, it most
definitely is the case, that we have multiple UIs on the same business
logic.
In
a good OO implementation, multiple UIs would reuse the same business
logic. With a BCE implementation it is not possible.
Now consider the 5 user interfaces for a web implementation each
with 5 interaction paradigms. If you build that cleanly with a separate
business layer encoding all the business logic, then you only have
to graft on a different UI - different control flow. It sounds to
me that this is what "you" have been doing but it is not what the
Rational Consultants are advocating whilst using the latest versions
of RUP.
What
"you" have been doing is much closer to the model I presented in
my MVC papers i.e. only the interaction control flow is captured
in a Controller layer - not the business flow. This is a crucial
point of difference. With BCE the business flow IS the application.
With the Sun reference model for MVC, the presentation layer (Views
and Controller) IS the application. The business logic exists on
its own.
In your example with the 4 use cases that include a login use case,
you state: "But must we also not instanciate a <> class
for UseCase1?"
The answer is that the control class would be instantiated for use
case 1, but this occurs when the user starts this use case, which
in turn would start the login use case, if required. RUP states
this rather clearly. Hence multiple control logic for a large number
of use cases is not started simulataneously.
I
think you are completely missing the point here. How do you know
which of the 4 use cases to start when the "Login" button is pressed?
There is no way of knowing unless the user has indicated which task
he wishes to conduct. However, in a good a-modal user interface
the user shouldn't need to indicate which task he is intending to
conduct. That is the difference between a-modal and modal i.e. tasks
are modal. If you have to indicate which task is being conducted,
you are clearly stating which "mode" the system should switch into.
This is crucial point and one which very few Rational people seem
to understand.
Furthermore, a large system will never have 400 use cases, unless
the author of the use cases has misunderstood the phrase 'a use
case provides observable value to an actor'. The largest system
I've seen (a national social security system of systems) had around
180 use cases. A public transport ticketing system for trains, buses
etc had around 50.
Well
I have worked on a bigger system. It had 3500 pages of Use Cases.
It turned into 1.5 million lines of Java. It had 600 distinct Views
in the UI. The requirements took a team of 18 people over 2 years
to write. The Use Case writing effort was led by the IBM Object
Consultancy.
I
believe that your objections are founded on the fact that you have
obtained good results whilst running RUP style projects. What you
should ask yourself is, "were these results obtained because of
RUP or because we worked around its deficiencies, or indeed because
we simply had really great people".
My belief is that RUP is not repeatable at any level over and above
basic procedural programming. Where I have seen RUP projects succeed,
it has been because of the people who were smart enough to work
around the problems.
In other words, they were not dogmatically following RUP. If you
reread what I wrote carefully you will see that I stated that I
do not believe that dogmatic adherence to RUP is repeatable or for
that matter will scale to significantly sized systems.
Thanks for your long and interesting letter. :-)
Cheers
David Anderson
Editor
|
