UML made Jacobson's use cases state of the art. What's next? |
 |
By Milan Kratochvil
08 Oct 2007 | SearchSoftwareQuality.com |
|
|
Use cases are about applications that interact with other systems or with humans rather than about object technology. As interaction decreases, so will classical "system" use cases, whereas Ivar Jacobson's business use cases will remain as useful as they are today.
Their connection to objects is mainly via Jacobson's great contribution to the forefront of both over the past decades. Nonetheless they specify an interactive system in a manner that's useful to both IT staff and their stakeholders whether or not the subsequent solution is object-oriented.
From the object perspective, it's virtually impossible to see any reason why use cases were so rare in traditional 'pre-object' projects. In the earliest days of the Unified Modeling Language (UML), use cases in some projects were almost like a religion, whereas today most projects have learned to use them as a practical technique. Yet, I've met quite a few IT people who still perceive the 'niche' and applicability of the technique as slightly hazy. Use cases are never thrown out by a compiler or code generator. They go into the "zero level" in model-driven architecture, the Computation Independent Model. That's the good news. The bad news is that you're never perfectly sure if your project is applying them to the right kind of requirements.
Fewer interactions
In my book UML Xtra Light, I point out the uncertain future of use cases, as automation rather than interaction makes some applications self-driven rather than event-driven. And over the past couple of years, research in both Business & Administration (at the Stockholm School of Economics) and IT (at the Swedish Institute of Computer Science, among others) seems to confirm this: End users prefer automation and "invisible" systems to interaction with a fancy GUI. Honestly, how many of us long to go back to a Windows version that repeatedly asks the end user how to exactly execute housekeeping programs such as ScanDisk? Even fewer seem to demand an Automatic Train Control system (or an electronic winter stabilization system in a car) that would ask the driver how exactly it should stop the vehicle.
Automation doesn't eliminate complexity, rather it transfers it from the outside (dialogs) to the inside (structure and logic). In my experience, this is a key reason for the stakeholders to go for a small smorgasbord of diagrams in requirements -- sometimes along with use cases, sometimes instead of use cases. Use cases are easy to learn mainly because of the template-based, almost slot-filling style of work they've brought along. This is mainly because they're more or less tailor-made for describing interactions.
Use cases' less formal kin (storyboarding, user stories, informal lists, feature points, feature-driven development) are broader and less dependent on interactions. But they're also less standardized/teachable because of their widened range; they provide more expressive power in describing functionality without distinct external interactions. On the other hand, as soon as the complexity to be described moves from the system boundary into the kernel of the system, it is better to go for the diagrams that have proven suitable in there over the past 11 years of UML (classes, packages, sequences, states).
So although the bullet list describing the dialog is the substance of a use case, the part that is most likely to survive automation seems to be the statement of purpose or business value of that use case. The system will probably be aiming at a very similar goal five years from now but perhaps without the human-computer interactions described in the bullet list of the use case.
What about user queries? Will there still be query subsystems available to humans 10 years from now? Most likely, yes. But as for use cases, almost all queries, as well as some routine system maintenance, can be described in just one parameterized use case (as I've shown in my book) which in turn fits into implementation in highly parametric query tools such as OLAP. Interestingly, in UML 2 there is a widened interpretation of parameterization (compared to UML 1.x). So in the long run, the number of classical use cases ("mid-level," that is system use cases) is likely to decrease. That is less likely to happen to business use cases, as they offer more expressive power in a graphical index of business processes than a plain process-hierarchy diagram would do as for business in general and ebusiness in particular.
More components
Downstream, at the use case realization end, components and open source are causing a shift from green-lawn design of software to component configuration. This is an efficiency-improving method that has proven very profitable in other engineering-intensive industries, including electronics/hardware.
Figure 1
In the increasingly frequent task of specifying a component or subsystem, some projects tend to define use cases in much the same fashion as when describing entire systems (Figure 1), whereas others prefer to show the interaction among components on a high-level sequence diagram (Figure 2), sometimes even showing components as packages (folders). It depends on the application and the stakeholder preferences; in requirements, they're often happy with drawing one rather than both. Figure 1 (a use case) is useful when the following are true:
- There are many and/or complex interactions with a component. (For example, a handshake obeying a complex stepwise protocol)
- The stakeholders have mainly non-technical roles.
- The invocation order of the components is likely to change. (In service-oriented architecture (SOA) and "ad-hoc" invocation, the exact sequence may differ from run time to run time.) Bank systems are an example of this.
Figure 2
Figure 2 (a sequence of packages) is useful when the following are true:
- Most interactions with components are straightforward messages
- The stakeholders are a bit more technical and interested in visualizing the involved components. (For example, hardware designers or product architects)
- The invocation order is less likely to change
Here, atop of the decrease in user interaction mentioned above, even components make "CEO-level" or architect-level sequences more interesting -- even outside the telecom industry where they've been around for more than a decade. Automation or telecoms or both ("telematics") are often an example of this. As an experiment, you might also try to swap the application areas between the figures. More than likely, that will feel less well-suited.
-----------------------------------------
About the author: Milan Kratochvil is an independent consultant and trainer based outside Stockholm, Sweden. He focuses on IT requirements, model-driven development and architecture in general and on variance, customization and configurability in particular. Milan is also co-author of UML Xtra Light -- How to Specify Your Software Requirements and of Growing Modular -- Mass Customization of Complex Products, Services and Software.
|
|
|
|
