UI RUPture
Can Rational Unified Process really facilitate a better experience?

As market demands get greater, traditional software engineering is marching full force into the web world. Out go the scripting hackers and in move the systems architects armed with J2EE specification and CORBA components and distributed transaction monitors and with all of that their software lifecycle methods such as Rational Unified Process. RUP is held up by many to be the silver bullet for object oriented success. Rational are pushing their business into the ".com" enterprise. However, several authors have expressed concern about the effect that RUP might have on the User Experience. Here is some of the latest analysis...

Rational Unified Process is a software engineering lifecycle method developed from Ivar Jacobson's Objectory (aka Object Oriented Software Engineering or OOSE) method from the early 1990s. The cornerstone of the OOSE and now the RUP is the Use Case. A Use Case is a form of Hierarchical Task Analysis which has found favor in the software engineering community.

In order to examine the effect that RUP might have on the User Experience, we must first make an examination of Use Cases then we must look at the detail of the greater Rational Unified Process and its end-to-end operations.

Use Cases

Use Cases have been discussed at length on this site in the past. In February 1999, this webzine warned that the widespread adoption of RUP may mean the "death of UI design". In October 1999 we looked again at how Use Cases might be useful through the development of Constantine and Lockwood's Essential Use Cases. Larry has more recently suggested renaming these Task Cases to avoid confusion with Jacobson-esque, Use Cases. Since then there have been several threads of letters to this site expressing concern over Use Cases and Rational Unified Process and how they adversely affect the User Experience.

Despite the fact that 2 years have passed since the original editorial, this webzine remains convinced that the widespread use of Rational Unified Process and Use Cases continues to adversely affect the user experience and lead to difficulties in the development process. Difficulties which practitioners are hacking around and trying to make-do, but the end result is still code which fails to meet expectations for usability. Why?

Constantine and Lockwood write in their 2000 Paper, Structure and Style in Use Cases for User Interface Design,

"For requirements engineering, use cases provide a concise medium for modeling user requirements; in the hands of user interface designers, use cases can become a powerful task model for understanding users needs"

This on the whole appears to advocate Use Cases and explains their wide adoption. However, one of the many problems is the variation in style recommended by at least the 7 leading authors in the field. Constantine and Lockwood continue,

"One of the more remarkable aspects of use cases is that they have achieved such wide currency despite an almost complete lack of precise definition"

James Rumbaugh, widely regarded as a stalwart on the Rational staff and a founding father of OO modeling techniques, defines Use Cases as follows,

"The specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem, or class can perform by interacting with outside actors, that yields an observable result of a particular value to an actor."

As Constantine continues,

"the current 'definitions' have moved away from Jacobson's original emphasis on use and have taken on what may be legitimately described as a more 'system-centric' viewpoint: The focus is on what the system performs not what the user does or wants."

This appears to be a very damning statement about Use Cases as a tool which will lead to a superior User Experience. If you couple this to the reality that Use Cases are seldom, if ever, written by someone skilled in user interface design or interaction design, then it is easy to see why Use Cases lead to a system specification which is ill-considered from a user experience perspective.

In the past, this has not been overly difficult to deal with. Simply take the Use Cases as a statement of requirement, extract from them a functional specification as a list of features, then as a separate exercise develop a UI design which meets the functional specification and leads to a superior user experience.

This approach allows for what Constantine has correctly recognized as one of the great advantages of Use Cases - their wide currency and broad acceptability as a means for expressing "what a system should do". Use Cases are reader friendly, whether that reader is a technical expert or a business leader.

Rational Unified Process - extending the problem

As we have moved through 2000, Rational have continued to develop and elaborate the Unified Process, advocating its use, with the intention of selling their tools to support it. In order to facilitate sales, the process has begun to get more and more elaborate and more and more detailed and consequently more and more proprietary. If the process were not detailed and elaborate, in a proprietary fashion, you might be able to follow it without buying Rational tools. That would be bad for business. Proprietary for these purposes means, deviates from the open standard. The current version of RUP does deviate from the version submitted to the OMG. So far Rational seems to have avoided the loss of mindshare which normally goes with a proprietary system. It appears that the market has yet to realize what is happening.

In the latest book to be published on the RUP, Philippe Kruchten, refers to it in Chapter 5 as "An Architecture Centric Process". In Chapter 6, he goes on to refer to RUP as a "Use Case Driven Process". Remember that Use Cases are a system-centric view of design. Kruchten goes on to reinforce that which we already have learned from Jacobson, Rumbaugh and Constantine. He clarifies the definition of a Use Case as follows, "A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor". He later defines a sequence of actions as, "The sequence of actions referred to in the definition is a specific flow of events through the system".

Is anyone noticing a theme here?

The User is never ever considered important in Rational's thinking about design. In their own words, it is "an architecture centric process" which defines "a sequence of actions a system performs".

In other words, Rational Unified Process is fundamentally NOT a user centered design method!

Actors

Rational Unified Process is anchored around a system-centric view of architecture but that system is acted upon through those series of actions by Actors. However, the UML definition of an actor is different from what the user interface designer might expect. As Larry Constantine recently observed,

the UML concept of “actors” is neither as rich nor as useful for model-driven user interface design as the concept of user roles employed in usage-centered design. Indeed, when speaking of human actors, the UML term is misleading, because it is the role not the actor that is most important for user interface design

Boundary, Control and Entity Classes

Sadly, it only gets worse!

Those of you who have been paying attention will by now realize that a use case is "a sequence of actions a system performs". In other words, just like any other form of task analysis, a use case is a "procedure". Design through use cases, leads to a hierarchical, architecture centric series of procedures performed by a system.

Those familiar with UI design will know that "procedures" are modal. A wizard is a procedure. In other words, a requirement document written as a set of use cases, is in fact the description for a set of modal wizards, each of which delivers some "observable result of value to a particular actor."

Any UI designer will tell you that a system designed purely from wizards is not very flexible or highly usable. It might support a few tasks but it will not scale to hundreds of tasks.

This leads to Anderson's First Observation on Rational Unified Process

Dogmatic implementation of the Rational Unified Process does not scale to significant sized applications.

Rational will counterclaim on this with case studies. However, at no time will they produce documentation to prove that the currently advocated version of RUP was used to produce the UI design, or demonstrate how changes in the UI design during development were accommodated in the finished code.

Rational Consultants working in the field are advocating the adoption of 3 stereotypes for classes in the class model. This technique is generally attributed to Ivar Jacobson (around 1994) with Grady Booch responsible for suggesting the adoption of the <<stereotype>> tags and icons now available in UML. Others have been involved in the development of this technique.

The technique is based on the principle that each use case should lead to the development of a control class. The control class is essentially a hard coded state machine which monitors the flow of a procedure from start to finish i.e. it controls the flow of the use case by processing each action in the sequence.

The sharp UI people will note that a View is generalized to a Boundary because a Boundary can be an interface with any Actor, and an Actor isn't necessarily a user but can be any other system, sub-system or component. This reinforces the notion that RUP is not a user-centered method.

In the example shown, a simple bank account query is broken up into 3 classes: one for the user interface view; one to control the flow of the task; and the third is an entity for the bank account itself.

Those familiar with good quality object modeling should immediately be suspicious of this suggestion. It appears to imply that the business logic for modifying the bank account be placed in the <<Control>> class, separate from the BankAccount data which is stored in the <<Entity>> class. Fundamentally, this breaks the notion of encapsulation. However, we have to be pragmatic. The Enterprise JavaBean specification suggests similar architecture, primarily due to restrictions on re-entrancy between Entity Beans. So perhaps we can discount the purist OO modeler objections.

However, let us consider some of the UI implications of encapsulating the task in a single class. Rational have proposed several models for this. One of the simplest suggestions is that each task is modeled in a use case. Each use case is modeled as a <<Control>> class and built as code. Then a user interface is designed which offers a top level menu choice for each task.

This would be equivalent to strategy #2 from the revisited chessboard pattern.

As explained at length in that paper, this strategy for a UI does not scale. It only support a small number of tasks - at most 20 or so. This reinforces Anderson's First Observation on RUP - that it does not scale. The Chessboard Pattern Revisited paper goes on to argue that the task strategy is perhaps the least desirable one of many available choices for an optimal UI design.

There must also be another fundamental objection to this approach. If you intend to code use cases as <<Control>> classes, then there must surely be a standard and controlled fashion for writing these use cases. However, as Larry Constantine observed in foruse #10,

most surprising in light of the roots of UML in use-case driven design, there is no standard way for defining use cases and describing their contents except as notes or annotations.

Roles as Actors

The third strategy in the Chessboard Pattern Revisited paper also lends itself to Use Case analysis but not to the Boundary - Control - Entity method for design. Kruchten suggests that use cases are focused on a particular actor, and elaborates that "Focusing on a particular actor forces us to isolate the value provided to specific groups (roles)". In other words, we could create top level menu items for each actor then drill down to the tasks for each actor as a second level choice. This will scale only slightly better than the previous suggestion. However, it should be immediately obvious that we have a dilemma. What was controlling that first level menu selection? We don't have a use case for that.

So we could get around that by developing a use case entitled, "Selecting a top level menu item". Then we create a <<Control>> class for that. Does this sound a little kludgy?

If we continued in this vein, we would quickly realize that some of the more powerful user interface design strategies from Chessboard Pattern Revisited can not be readily implemented using Boundary - Control - Entity modeling, unless we significantly embellish the design with a lot of kludges to work around the holes.

Encapsulating a task in a class hard codes the UI design

The next severe difficulty which becomes apparent with the B - C - E approach is that the encapsulation of a task in a class, appears to hard code the user interaction. That hard coded interaction is based on the use cases which were often written in order to specify the requirement. And as has been pointed out by many authors, use cases are usually written by business analysts or system analysts but seldom by user interaction designers.

The result can lead to developers coding up procedures which any decent UI designer will want to discard! Why?

The art of user interface design is often that of simplifying tasks or allowing them to be conducted partially, or in any order. This is facilitated by trying to develop an a-modal design. An a-modal design is the antithesis of a collection of modal wizards. A collection of use cases implemented as <<Control>> classes is by definition a collection of modal wizards. So how do you facilitate a-modal UI design with RUP?

Well Rational have answered this by stating that "the UI design should be completed as part of the requirements phase!" So in the supposedly iterative Rational process, the UI design becomes the poor cousin which must be completed in a waterfall method. Again, from ForUse issue#10, Larry Constantine observed,

user interface design is seen as a requirements activity rather than a design process.

Once, that UI design is thrown over the cliff and the interaction is set in stone as part of the use cases, it cannot be easily changed.

Why not?

Simple! If you start coding classes with procedures, and the UI designer comes along and merges two of them together, chops one up slightly and then pieces part of it into another one. Are you really going to try and rework all that code, all those <<Control>> classes with subtle business logic embedded into it?

Almost certainly not!

This leads to Anderson's Second Observation on Rational Unified Process

RUP does not lend itself to iterative user interface design

The sharp OO purists reading this should also have spotted another fundamental flaw. If you are coding business logic into <<Control>> classes and those classes are modeled after modal procedures called use cases, then what happens if two or more procedures require the same business logic and access the same entities?

Well the reality is that the most popular form of code reuse is required - cut'n'paste!

Rational would answer this by saying that proper use case modeling, where all use cases are accurately subdivided down into sub-use cases would eliminate the problem. In other words, thorough and flawless hierarchical procedural modeling is required, in addition to flawless class modeling. In fact it could be argued that, Rational are advocating Structured Programming through procedural decomposition. RUP is in effect, procedural analysis and design wrapped in object technology. We could be doing it in Pascal!

This leads to Anderson's Third Observation on Rational Unified Process

RUP places extreme reliance on the poorly understood process of use case modeling, at the risk of duplication of business logic in the <<Control>> classes

Use Case modeling into sub-use cases leads to the final serious user interface problem which can be observed with the currently proposed B - C - E method.

Consider if you will, this simplistic example of a use case model. In this example, we have a system which contains 4 tasks, each modeled as a use case. Each task requires the user to login to the system before the task can be completed.

Imagine for a moment that a full ui design was completed before the use cases were written and that an optimal a-modal design is available. Imagine that all the above observations and difficulties were somehow overcome.

Now the user presses the "Login" button!

What happens next?

Well I hear you say, we must instanciate a <<Control>> class for the Login use case! Correct!

But must we also not instanciate a <<Control>> class for UseCase1? Afterall, that procedure has started and we must monitor it? If that is true, must we not also instanciate a <<Control>> class for UseCase2, and UseCase3 and UseCase4?

Now let us imagine that this is a system with 400 use cases and all of them happen to need this highly reused sub-case!

This would appear to be yet further evidence for Anderson's First Observation - RUP doesn't scale to big or even medium sized system problems.

Continuing with the example, so now we have 5 <<Control>> objects instanciated. We now have to maintain all 5. When "Login" is complete we can destruct one object, but the other 4 remain. How do we decide which is the real one? Well it seems that we must monitor what happens next in the UI and try to assess which is the real task that the user is undertaking. At this stage it is too early to tell.

In other words, we must run 4 procedures concurrently because our a-modal UI design allows this to happen. The user doesn't and shouldn't need to indicate to the system which task is being undertaken.

Now let us consider that all 4 tasks are in fact very similar and all 4 touch the same <<Entity>> e.g. BankAccount. It is very likely that all 4 <<Control>> classes have similar business logic and modify the same <<Entity>>. How do we ensure the integrity of the <<Entity>>?

All of this gets very very messy.

Summary

It appears that Rational still have a long way to go developing the Unified Process. If the Boundary - Control - Entity method is to be widely adopted, they will need to produce a number of White Papers explaining how it is done, with real worked examples. These examples will need to address the very real concerns raised in this article.

Rational continues to pursue the adoption of RUP as an industry standard. As part of this initiative, they are sponsoring an OMG Workshop in October 2001 entitled, "UML for the .com enterprise". If UML is to be adopted by the ".com" world, it must become a common language which can be used by web designers, graphic designers, interaction designers and usability professionals, such that it can be used across the whole of a ".com". The benefits of such an initiative will be enormous. A common language in which to specify a design and then hand it off to the software engineering team will lead to higher quality and faster, better results.

Currently, UML falls far short of the mark. As Larry Constantine noted,

UML provides neither a diagram type nor a notation for representing user interfaces in either abstract or realistic form. Neither is there any model or notation for modeling user interface architecture, that is, the various views or interaction contexts to be provided to the user and the interconnections among them.

The OMG needs at the very least a Special Interest Group for User Interface. It may fall to the author of this article to form one. Even better would be a User Interface for UML Domain Task Force. Such a task force would need to include members of the web design, information architecture, interaction design and usability fields. The rallying cry came once again from Larry Constantine in ForUse issue#10,

All is not lost. If the right people lobby the OMG with sufficient fervor, the UML notation can be fixed. (1) System actors (other systems and machines) must be distinguished from user roles. (2) The notation should support structured contents of both user roles and use cases. (3) The UML “use case diagram” needs to be improved by using distinct line types for various relationships. (4) Most importantly, models and notations for abstract prototypes and interface navigation maps must be added.

If Rational Unified Process is to become the process of choice for the ".com" enterprise then it too must address all the richness of the skills involved in producing a website. It must seek to become a process which embraces user interface, interaction, graphic design and usability. It must seek to become a process which facilitates a superior user experience, not just a superior systems architecture.

Both the OMG and Rational needs to engage the web community, and the UI Design community in order to move towards a better result. The current Rational Unified Process is totally inadequate as a process tool for the ".com" enterprise, and no amount of elaboration on how to implement a <<Control>> class will solve that problem. Rational must address the fundamental issues of User Centered Design and A-Modal design. They must demonstrate how it is possible to do iterative user interface design while the system is in development and how that can be accommodated within the Unified Process. They must return to Jacobson's original intention for the use case - user centered requirements gathering.

Until this happens, no ".com" in its right mind should dream of using Rational Unified Process.

Notes following publication:

Several commentators who have not consented to publication have observed that although the BCE technique is part of RUP, it is only advisory and it not suggested as the only way of modeling an application. You can, therefore, by implementing RUP without doing BCE style modeling. Regardless of this fact, no one denies that Rational Consultants teach this technique as part of the process.

Acknowledgements:

Thanks to Dave Roberts of IBM's Ease of Use Group and Larry Constantine for review comments, prior to publication. Further thanks to George Davis and later Philippe Kruchten for correcting some of the inaccuracies in the first edition, after publication.

References:

Philippe Kruchten , The Rational Unified Process, 2/ed, Addison Wesley, 2000

Jim Conallen, Building Web Applications with UML, Addison Wesley, 2000

Larry Constantine, Foruse : the Electronic Newsletter of Usage-Centered Design || Issue #10 | December 2000

Larry Constantine and Lucy Lockwood, Structure and Style in Use Cases for User Interface Design, extract from Object-oriented User Interface Design, M. van Harmelen, editor, 2000

Stan Ward and Peter Kroll, Building Web Solutions with the Rational Unified Process: Unifying the Creative Design Process and the Software Engineering Process , Rational Corporation, 2000