What is USP?
USP stands for Use Case State Model Pattern. It is an application framework used for creating software that allows systems to be
Robust
Adaptable
Reliable
Maintainable
Reusable
Scalable
Understandable
USP is an architectural framework that incorporates modern, proven software engineering techniques with code generation. A common application of USP is in GUI development. Scalable systems partition the user interface (e.g., a GUI) from other subsystems so that when changes are made to the GUI, other parts of the system are not affected, and vice versa. However, they do so in a non-standard manner. USP adresses this and other architectural issues by combining patterns like MVC with Use Cases, Finite State Machines and Observer in an easily understood manner.
The concepts behind USP are not original, nor are they new. They are simply an attempt to put into use, in a standard way, proven techniques for developing sound software. What differentiates USP is that it combines a few of these well known architectural patterns into a process that can be applied consistently and uniformly across a wide range of applications. In fact, it can be argued that this framework is suitable for any development task of any kind. There are tools being developed that can be incorporated into products such as Rational Rose™ to aid in implementing the framework, but these are not necessarily required. (However, they certainly make the process faster and easier).
Let’s quickly review the major concepts behind USP, namely Use Cases and State Models.
Use Cases
The Unified Development Process (UDP) defines Use Cases in terms of a Use Case Model, which is comprised of Actors, Use Case Diagrams and Use Cases. Use Cases, by definition, codify a user’s interaction with a system in a particular context. They are the requirements for a given system. The major problem with “traditional” requirements is that they are simply stated without context (e.g., “The system shall…”). As they say, “context is everything”. In USP, the context is the Use Case itself. Use Case Context provides scope for a given set of requirements based on how the system is to be used. Proper implementation of Use Cases ensure that requirements are met, and lend to more adaptable systems in that the systems can at least be made aware of changes more easily than if requirements are buried in some other form of document. What could make more sense than that?
We have presented Use Cases as the primary tool for ensuring that requirements are properly met in system development. What has been your experience in this area? We find that most software development managers that employ Use Cases delegate the task to a few unfortunate souls who create a bunch of documents that somehow ultimately get lost among all the other artifacts of a development effort. Or they punish an entire development team by forcing everyone involved to create these documents with a poor understanding of how to create them properly in the first place. In either case, the Use Cases end up being outdated at the very best, and ignored or lost in the worst case.
In general, programmers hate preparing Use Cases as much as they hate any other document preparation tasks, primarily because preparation efforts can take valuable time away from design and coding. They know that these documents will ultimately be ignored, and that because they take time away from the project now, programmers will be asked to essentially work for free to play “catch up” as the project rolls on and the inevitable deadlines loom. Note however, that this failure rests on a very fundamental tenant:
Programmers don’t like Use Cases because they
are of little use to programmers
Okay, but why? – Two primary reasons: (1) Sometimes organizations don’t understand how to develop effective Use Cases, and (2) Use Cases are not source code. Let’s address the first concern: USP does nothing to ensure the proper production of Use Cases. We recommend the book “Use Cases : Requirements in Context” by Daryl Kulak and Eamonn Guiney (ISBN 0-201-65767-8) as the best guide available. Granted, there are other excellent sources of information, but the process employed in this book is so compelling that programmers who read this book actually get excited about using Use Cases! In addition, one may consider quality training from a programmer's perspective. Too many Use Case training courses focus on the management view (as opposed to the programmer view). Of course, Use Cases are excellent management tools - perhaps the best for a UDP development effort. But unless programmers understand how to convert them into code, they are not being used to their full potential.
Now to the second concern; In any real system, code rules, not documents. Unless documents can be engineered in a round-trip fashion (so that they are kept in sync with code), they will always somehow disappear or become irrelevant. One way USP addresses this concern is by representing Use Cases (and States) as full-blown objects in their own right. So what is a “State”?
State Models
State modeling has been in use for many years, especially in “real time” software (and hardware!) development. Engineers use them all the time. Indeed, it is difficult to imagine an engineering course that does not include coverage of their use. State models are also known as state transition diagrams. They are used to model finite state machines, where a system (or subsystem) is known to be in only one state at a time. Further, the subsystem (in this case, a program module) can move from one state to another ONLY by means of a small number of legal state transitions. This lends to the reliability, robustness and provability of a system. Like Use Cases, State Models are fully incorporated into UDP. A sample state diagram is depicted below.
State models can be used to represent behavior of a system, an object or a Use Case. Can you guess which one USP uses? That’s right, Use Cases. In a nutshell, USP requires every Use Case to incorporate a single State Model. This Use Case State Model represents the state of the Use Case itself. Again, this is not a new concept and can be traced to Craig Larman’s outstanding text “Applying UML and Patterns”, (ISBN 0-13-748880-7) among others. The difference here is focus. USP requires this step where other methodology approaches present it as a somewhat curious “optional” approach.
Conventional wisdom holds that state modeling is wholly appropriate to the “real time” domain, but it is of little use in other application domains, especially corporate information systems. Nothing could be further from the truth. State models not only make the task of programming easier, they are the only known mechanism for ensuring certain conditions are met (or not!).
The Problem with Use Cases and State Models
Of course, there is nothing inherently “wrong” with either Use Cases or State Models; they are adopted without modification into the USP framework. As with most tools, the question isn’t whether the tool itself works, rather it is “When is the most appropriate time to apply the tool?” The answer in most projects is, “We don’t have time for that.” Why don’t we “have time?” We believe it boils down to three major issues:
Confidence – The development staff is not confident that the
extra effort expended will result in a better system
Implementation – Since Use Cases and State Models are not
typically represented as “first class citizens” in most designs, they never get
implemented in code
Completeness – There is no way to ensure that the Use Case and
State Models will be reflected in the final product
Without actually employing the USP framework, the first concern cannot be addressed. Let us simply state that proper application of the USP framework takes care of this concern. We contend that once USP is put into use, a development organization will choose to continue its use because it obviously fosters so many of the desirable characteristics we seek to infuse into our systems.
The second and third issues (implementation and completeness)
are addressed directly by the framework in that Use Cases and States are directly
implemented in source code, as we mentioned earlier. At first glance, it would
seem such a practice departs from most modern OO development practices in
a big way in that the conventional approach is to somehow “discover” objects
that take on this responsibility of implementing the Use Cases and behavior.
Properly implemented USP code actually does not displace this activity; rather
it provides an architectural layer that enhances this activity by providing
better scope and scalability. This architectural layer is built up from patterns,
the third leg and final of the USP framework.
Patterns
The USP framework incorporates many patterns into its implementation, most notably the Model-View-Controller (MVC), Observer and Command patterns. One can use USP without even being aware of these patterns, yet they lend to its power tremendously.
Components of USP - Application Objects
USP is made up of five primary types of components:
An Application Coordinator, a singleton
A User Interface (optional)
Multiple Use Case Controllers for each
Application Coordinator
Multiple States for each Use Case
Controller
Multiple Domain Objects for each State
These object types are more or less layered in a USP application as follows:
|
Application Coordinator |
|
User Interface |
|
Use Case Controllers |
|
States |
|
Domain Objects |
The top four layers are “USP Application Objects”. This means they are not candidates for reuse. The bottom layer (Domain Objects) is most definitely a candidate for reuse. Let’s take a look at these in more detail.
The Application Coordinator
The Application Coordinator represents the application itself. No matter the system, there is always an entry point (e.g., main()) that is invoked at the process level that begins execution. USP recognizes this fact and uses this singleton object as the gateway into the Use Case Controllers. It is also a convenient location to place global system resources, but in general, this practice should be avoided. In short, if a Use Case Controller, a State or a Domain Object require the services of a system resource, they should invoke them directly rather than binding to the Application Coordinator.
The User Interface
The User Interface follows the canonical notion of a user interface, be it a graphical one in the form of a GUI or a non-graphical one (e.g., a protocol). The User Interface is the entry point for Actor actions, typically modeled as Boundary Classes. The User Interface is controlled by or provides data to various Use Case Controllers. For example, if there is a “main screen”, it may be invoked by the “Start Up” Use Case.
The Use Case Controller
A Use Case Controller represents the Use Case itself. It is a controller in that it processes the steps of the Use Case, but not necessarily in the order defined in the event flows of the Use Case. This is the job of the State objects. Recall that a Use Case is actually more like a class than an instance in that multiple Scenarios implement a Use Case. Rather than attempt to model the relationship between Use Cases and Scenarios, USP delegates implementation of the Use Case to State objects. State objects are better geared to process more granular behavior in a reliable and predictable manner.
Use Case Controllers are usually self-contained, but in some cases they must gain visibility to other Use Cases (e.g., when they play the role of triggers). Such access is provided via the Application Coordinator. The Use Case Controller object may or may not be a singleton, depending on the nature of the use case.
The State
State objects literally represent states in a UDP state diagram. Transitions are not full blown objects. They are merely named literals, as in Smalltalk. In general, States do not even know about other States, unless they are predecessors in the same Use Case. There are however some exceptions when we consider the fact that Use Cases can be concurrent in that multiple Use Cases may be (and often are) active at the same time. This implies that an application can be in multiple states at the same time, which may be perfectly acceptable. Because Use Cases are “first-class citizens”, USP provides an awareness when this occurs, as well as the means to control Use Case concurrency programmatically in a standard manner.
A NOTE ON REUSE: As we said earlier, none of these first four component types are considered reusable; they are specific to a particular application by definition. That is why code generators are employed and we refer to them as USP Application Objects. Use Case Controllers, Application Coordinators, States and User Interface objects provide an architectural layer around more conventional “domain” objects, which are to be reusable.
The Domain Object
USP Domain Objects correlate directly to the canonical notion of a Domain Object as represented in most all OO literature. (Domain objects are synonymous to the Model in MVC). Active USP State objects invoke operations on more passive Domain Objects or interfaces (such as “Customer”, “Person”, etc.) to implement the state of the Use Case.
Coupling And Cohesion
Scalable software requires loosely coupled components. Effective software sometimes requires highly cohesive components. These two concepts are very important, yet they are inversely related. To gain more cohesion, one must relax coupling, and vice versa. How does USP address this common development quagmire?
USP and Loose Coupling
Suppose an Actor clicks a button on a User Interface that is part of a USP application. The GUI is coupled through an Application Coordinator to a Use Case Controller that propagates the event ultimately to an appropriate State object, which then invokes the methods of one or more Domain Objects. If any data is returned, it is passed from the state back to the GUI via the Use Case Controller. This approach works well when communication travels from the Use Case to the Domain Object, but what about communication in the other direction?
USP supports loose coupling by implementing a form of the MVC pattern. It allocates specific behaviors to specific components and ensures that Domain Objects have no knowledge of any of the other objects in the USP framework except an Object Bus. So, Domain Objects act as passive servers that have methods invoked by clients. The only active role Domain Objects play then, is to fire events. The definition of these events are NEVER imposed by USP. Rather they are events that the Domain Object already implements. And so there is some coupling (there has to be in order for objects to communicate) but it is limited to a single event service as opposed to a gaggle of application-specific components which comprise the other four types of USP objects.
Why such a focus on loose coupling? For the same reasons that motivate the MVC pattern: namely that boundary objects can change without affecting Domain Objects, and vice versa. The other “prime directive” is to keep the Domain Objects pure – completely uncoupled to any application-specific objects.
What about coupling between other types of USP objects (i.e., Application Coordinators, Use Case Controllers and States)? Interestingly, there is nothing wrong with these objects having full knowledge of each other, within the scope of a Use Case. When we consider the implications of coupling code that is not reusable to other code that is not reusable, the trade-off can be moved in the direction of favoring tight cohesion over loose coupling for the other three types of USP components. Of course, this does not imply that we should abandon sound practices of encapsulation, etc. All we are saying is that certain visibility rules can be relaxed to promote say, performance.
USP and Tight Cohesion
Suppose a GUI changes (say someone decides to change the name of a widget or to add or remove widgets from the user interface). This may affect the Use Case Controllers. Further, these changes may bubble down to affecting the State objects. So what? As long as the reusable Domain Objects are not affected, who cares? So in USP, Use Case Controllers have full knowledge of GUIs and States.
On the other hand, should we make these objects publicly visible outside the scope of the application? Although we could, there is clearly no benefit in this approach – all it does is hog the namespace. So, although these objects know about each other, other objects (and non-related applications) do not know about them. So, they are tightly cohesive among each other, but are effectively invisible to outside clients. In most cases, the only classes with public visibility in USP are the Application Coordinator and the Domain Objects. The only exceptions are some concurrent Use Cases and Use Cases that trigger other Use Cases.
Employing USP
By studying the USP framework, you can create your own implementation or you can purchase a USP implementation.
So what are the steps involved?
Here they are in order:
Review Information on Use
Cases and State Models
Determine State
Classes
Generate or create USP
Application Objects
Choose appropriate Domain
Objects to implement Use Case States