Making Implicit Use Cases Explicit

If I could attach a number to something, it would be how many implicit use cases materialize during the development phase of any given project. They outnumber the explicitly spelled-out use cases. It's a little difficult to define what, exactly, an implicit use case is. Is it all the valid use cases of the system that were just overlooked? Do use cases include malicious intent by the user?

The trouble is, use cases generically capture the intended usage patterns by users. The user wants to get to point C, so we need to get them through A and B. And this works because it explicitly states the what. If we have a collection of these generic use case statements, we can use them to ensure we are in fact solving the problem we've set out to solve. But when new software is crafted, new problems are introduced — new opportunity for miscommunication and human error.

What happens is the implicit use cases that went unnoticed saturate the design and any code written. Not only do you have to deal with these cases when they're inevitably discovered, but you're also taking a mental hit. Finding missed cases when you think you've got it all covered hurts morale. This is no different from the waterfall approach — when big upfront design fails, it fails hard. Explicating all possible use cases isn't feasible either. This is almost waterfallesque, trying to foresee the unknown. Perhaps a better organizational schema for tackling the problem of implicit use cases is to group them by personae.

Generic Use Cases
The practical aspect of use cases is they capture a generic scenario. For any given function of the system, we can make statements about what that functionality looks like from the actor's point of view. And they're the same for all actors. So we have this relationship between an actor, also generic, and a use case. This says that we can reasonably expect a certain commonality across the users of our software. This assumption is necessary, because you can't sit down with each individual that plans on using your software, interview them, draw up the use cases based on their personal preferences, and make the corresponding code modifications. Practicality dictates that we come up with a template. One that best represents why we're building what we're building.

Generic use cases are challenging enough to manage, even with the reduction in complexity due to common user expectations. Imagine that your software's user-base were all clones of the same person with the same personality traits, the same knowledge of your application, the same everything. With this in mind, you could simply go about documenting how these clones would go about interacting with your application. Every situation presented to them would prompt the same response. So with the human variables removed, you're free to focus on the use cases themselves, and avoid the relationship between the actor and the use case.

By and large, this is how we design software today. We take the set of human clones and apply formulated use cases. We establish the generic link between actor an use case. The positive angle to this approach is that we can easily manage these relationships. Just like when you design a class hierarchy, you put the common structural and behavioral features near the top. This allows our brains to think generically, as opposed to having to specializations straight away. Use case definitions work in the same way — we focus on the top level of the class hierarchy, trying to document the common use cases for the common user. This is a good way to get started with the requirements of your system, but just as with class hierarchies, specializations must be put forward.

Specialized Use Cases
The generic, templated approach to use case design work is where implicit use cases originate from. Consider our group of user clones again. When they're using the application, everything is fine. But introduce another set of clones, based on a different individual, we start to see some interesting things happen. Because the generic use cases that our system is based on really only considers one persona, we can't accommodate another. Of course there is some level of overlap between the two groups of human user clones, and that is why we design use cases generically to begin with. But not everything overlaps. There are individual differences that need consideration.

The differences in user personae are the reason we require specializations in the use cases of our software. They're the reason why the relationship between between actor and use case are important.

To remedy this problem, we employ user experience design, as is the standard practice today. More often than not, the user experience design activity occurs after the generic use cases of our system has been captured and finalized. This is what our software will do, so let's make sure the experience of doing those things is pleasant for each personae. This works from a user interface perspective, but the improvements seldom end there. Whichever persona we're improving upon, will often require more than a simple rearrangement of user interface components. The changes in improving the experience for any software tends to trickle, top-down, into it's roots.

The generic approach to use case design is feasible, this is why we do it. My suggestion is that we take it one step further and think more deeply on the user experience design at this stage. User expertise at use case time, perhaps even before the user interface code exists, is invaluable. There are bound to be a few light bulbs that have far-reaching consequences in terms of how your code looks all throughout the system. You don't have to go about this histrionically either. Even two or three personae taken into consideration during use case discussions would help.

Simple Blog Use Cases

How do system designers illustrate the intended use of the system in question? One of the common standards is to draw UML use case diagrams. The core constituents of use case diagrams are actors and use cases. The actors are can be anything that is external to the system, but are often human users of the system. The use cases themselves are high-level goals that need to be realized by the system in order to keep the actors satisfied.

The key thing to remember with use cases is that they are purposefully a high-level concept in system modeling. They are there to explain, visually, what the system is to do. Since use cases generally shouldn't delve into much detail about what the system is supposed to do, these diagrams are often useful for showing to non-system designers.

Within UML use case diagrams, use case elements can have relationships with other use case elements. These relationships are of the extend or include variety. Illustrated below is an intentionally simplistic, incomplete blog system use case diagram.



In this example, we have to actors; Blogger and Reader. A lot can be inferred from the actor names alone. One probably doesn't even need to look at the diagram to realize that a Blogger publishes content and that a Reader reads content. Consequently, each actor has a single base use case. The chief use case for a Blogger using the system is to Publish while the chief use case of the Reader is to Read data from the system. The chosen names fit nicely with what is expected from model readers.

We do, however, show a few other use cases that are related to the above mentioned cases. The Edit use case is included by the Publish use case. The reason this relationship is an include relationship is because publishing can't happen without editing content. Here, we have explicitly taken the editing out of the Publish use case. The Publish use case is extended by the Upload use case. The reason this relationship is an extend relationship is because the system doesn't need to support uploading capabilities for all publishing functionality. However, it is shown explicitly here that it is required functionality. Finally, the Read use case is extended by the Subscribe use case because subscribing is reading from the system but isn't a requirement.

This example probably doesn't show even half of the potential use cases of interest for even a simple blog system. But I think that this is a good this. At least I think less is more when it comes to the individual use case diagrams. All use cases may be captured in the model but I would suggest breaking the use cases into several diagrams. Especially when extend and include relationships are involved. I find that when too many of these relationships are placed in a single diagram, it defeats the purpose of high-level system functionality illustration with simple notation.

User interface testing

Although there are several tools available today that enable the automation us user interface unit testing, they are not ready to use as the only testing procedure of any given application.

There are several issues that these tools fail to catch. Mainly, the work flow errors. Your application could pass the GUI testing framework with flying colors and yet, once your application is human-accessible, it fails colossally. This is because the slightest misinterpretation by the testing framework as to what the work flow should look like (work flow in this context is the sequence of user interface actions, not application logic). This is not to say that the user interface testing frameworks are not capable of fully automating the interface testing, it is a question of effort involved. A simple user interface validation test done by a human may take an hour to perform where designing a test may take much longer.

In the long run is it worth it? Maybe. If your application is user interface centric (some would argue that all applications be designed using the interface as a starting point), it might make sense. In this case, the user interface designers will most likely be designated to this task. They will not likely care about application work flow.

What if you are in a situation where the user interface takes a "back seat" to other "more important" tasks? Well, this is bound to happen. After all, a user interface with no application behind it isn't terribly useful. Perhaps what is needed here is two sets of use cases. One for the application, which is independent of how external actors interact with the system. And, one for the user interface that describes the interface cases in much detail while keeping the application cases vague.

Use cases from the perspective of software objects.

Use cases from the perspective of software objects? What does that mean exactly. Well, it is misleading in the context of contemporary use case modeling. When I first encountered use cases, I have to say I was less than impressed. There are actors and uses cases. Big deal. Why can't we just hear what needs to be built, go out and build it, and iteratively evolve the software accordingly. Boy was I wrong.

The importance of understanding what is being built is so important that it cannot be underestimated. Especially as software grows ever more complex.

Typically, actors are the users of the system being modeled. For example, you may have a user actor that represents a generic user of the system. You may also have an administrator actor that inherits from user. This works well for modeling the actions the users of the system can perform as well as actions only administrators can perform. Actors also represent external systems in use case diagrams. This provides a new perspective of how your system uses external systems or how your system is used by external systems.

But what about modeling software objects as actors? This is completely valid and a very powerful abstraction tool. Modeling what your system will do in a standard use case diagram is a challenging task on its own. The next step is to realize this functionality. Once some software objects have been conceived, we can then conceptualize how these objects will behave by modeling them as actors in a use case diagrams.

Alternatively, software objects can be modeled in use case diagrams as the system boundary, or system context. Your software object essentially becomes the system you are modeling.

Modeling software objects as in uses cases can help discover interfaces that your various objects will both require and provide.