Rational and UI
more feedback on Use Cases Again!

David,

Just a short comment, have you ever tried to use use Rational-Rose? ....

I think that this clearly proves your point about the lack of UI knowledge and expertise at Rational. I was the UI designer in a company that adopted the Objectory process and baought Rose as a modeling tool. After struggling with trying to use it for a few MONTHS, we ALL agreed that we are going to use word processors and Visio instead. It is truely one of the most horrible UI experiences I have ever had.

Erez

Hi.

Sorry. Didn't have enough time to read more of your articles on uidesign.net but at first glance your negative opinion about use cases seams like trying to bring programmers point of view to the client face. In my opinion analyst makes use cases listening to customer. And this is a preliminary rough artifact witch allows designers and programmers work without direct contact with customer. They simply use analyses artifacts to refine system's model. I believe your position steams from habit to show clients result of your work: user interface. What about deep features of system which are not visible to anybody in company beyond designers and business analytics?

Best regards,
Denis Starikov.

I read with interest (and some alarm) your comments about the Boundary-Control-Entity class model, but have not been able to find additional material to help me understand the pattern and its impact on interaction design and designers. Can you point me to additional information, or give me a quick description of what this model looks like? I'm familiar with UML and with many commonly used design patterns, but you lost me somehow when you described the sequence of elaborating use cases with activity diagrams, then building the activity diagram as a Control class, in the sense that I don't have enough information to understand how that "makes UI design redundant". Are you saying that's true simply because it isn't explicitly inserted as a part of the process during/after use case creation, or that the Boundary-Control-Entity model itself somehow locks out interaction design. I guess I'm too visual or something, because I'm not following you. ;-)

Thanks,
Dan Davis

uidesign.net reply...

Hi Dan,

The real issue here is that you only get one chance to get it right. After that the pain of change is too great. Couple that with the fact that the Use Case is always never written with the involvement of a UI Designer and your heading for trouble.

There is a 2nd issue. I do not believe that the BCE approach scales to any size at all. Use Cases are procedures. When you describe a whole system with them, you describe a series of procedures. If you then hard code those procedures, you have byb default built a system of modal wizards.

The job of the user interface designer is often to work through the task analysis / procedure descriptions / Use Cases and design from them an optimal user experience based on an a-modal environment. In other words a UI which supports swapping between tasks, doing tasks in any order and so forth.

With BCE this is not possible. The only solution is the procedural modal one. Hence the job of the UI designer to produce an a-modal design is lost. The UI Designer is redundant and good UI design is dead.

When you couple this to the fact that it is very easy to poke a hole in the Controller class idea, the whole thing just doesn't gell.

For example, imagine a sub-use case called "Login" which is composed into many other Use Cases. The User presses the Login button on the screen. The system plumbing then says "Ah ha, this is the "Login" Use Case. What happens next, it determines a number of control classes which need to be instantiated. One for each of the possible main Use Cases that are composed into the Login Use Case.

This is nonsensical.

As the User proceeds through the interface the code would constantly have to assess which of the control classes it had instantiated are no longer needed as it becomes obvious which of the main Use Cases is actually being followed. These "extra" objects would then have to garbage collected.

Then there is the maintenance issue. With a BCE approach, you have hard coded the user interaction into a class as lines of Java or C++ or whatever. If you want to make a minor change to an interface, you have to go and re-write the control classes.

Then we could look at the re-usability of these control classes which is really non-existant.

Moving on to the Activity Diagrams. This is the latest material which was presented at UML2000, the recent OMG conference. The essence is that you use the Activity Diagram to elaborate the Use Case to get something from which Control logic code can be built. An Activity Diagram is to a Use Case what a Sequence Diagram is to a Class Diagram.

I hope that helps at least as partial expalanation.

Regards,
David Anderson
Editor

My company has started using Rational as well. I am responsible for UI design and documentation. Although I am not especially enamoured of RUP, I do not think it has to be the "death of UI design." In fact, we are using it to make our most user-centered product ever. RUP definitely undervalues and does not understand either documentation or UI design, but it is possible to use its tenets to support both. I noticed that one article linked to this one, "Are use cases the death of good UI design?" opined that use cases were dangerous because of the design suggestions embedded in them. As I understand it, use cases ought to be written independently of design. If not, then you lose the stated benefit of being able to reuse use cases for future projects. When I wrote the use cases (as the use case specifier, who does not need to be a business analyst or coder), I did include some design constraints as I thought of them, but I carefully separated them from the main flow. Once I started prototyping the UI and putting together a navigation map, I pulled the design constraints out of the use cases.

Overall, I found use cases to be extremely beneficial to the product, because it forced the developers and managers to think about how the product would be used. I cited the RUP as justification for user testing, prototyping the UI, and for separating the UI from other layers of code.

I agree that Rational ought to hire qualified documenters and UI designers to adapt their method. It is all too easy for engineers to use the RUP as currently defined to reinforce bad practices, especially given the horrid templates they provide. However, a motivated design team can find plenty within the RUP that supports good, user-centered practices.

Kathleen Pierce

uidesign.net reply...

Your note really highlights the value of people in the triad of "people"-"process"- "technology". My biggest issue with RUP is that it doesn't help to reduce the emphasis on people. Therefore, it is not truly repeatable. A repeatable process should/ought to be repeatable with a broad base of developer ability. Meanwhile, I am impressed with your approach and ability. If you would ever like to come to Kansas City, I can offer you a good job :-)

David

Kathleen Pierce wrote:

A note re my original letter: It probably makes a difference that I am at a small company, where we do not have the infrastructure or knowledge to implement the RUP in its strictest form. I probably have more latitude than many people do to interpret the RUP and adopt procedures that fit its basic tenets but perhaps not the details it suggests.

hello,

about your article: Use Cases Again - revisiting the IMHO from February 1999

Isn't this what you wanted for the project / (web) application? All members of the project team intent on delivering a product developed with the user at the center? Perhapse your discipline will have a shift in focus from a boxed specialisme towards a more advisory and proces driven task but change is nothing new. I do agree that the current way Rational views the user interface role, have you checked how little the graphic artist has been updated to the 2001st century?, is not at all optimal,

grtz,
michaud

uidesign.net reply...

I fear that according to the recent Kruchten book published by Rational, "Rational Unified Process is an Architecture Centric Process" i.e. it is not a User Centric Process. That is a large part of the problem. In the Rational world they appear to have a very poor understanding of what a user is and why they might - just - be important.

David Anderson
Editor