![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Requirements gathering is an essential step in any successful software development cycle. There are numerous requirements gathering methodologies, but the most common method is use case modeling. We've partially worked through sequence diagrams in conjunction with use case modeling in the two previous columns. This time I'll talk more about the theory behind the method, and also expand your modeling vocabulary a bit.
I'm most concerned in this discussion with clarifying the relationship between user interfaces, system interfaces, and use case descriptions. Because most of the systems you build will be designed to interact with people, it's tempting to devise your use case descriptions starting with the user interface. But including user interface logic in a use case is generally considered bad form. The short explanation for this is that the user interface provides a view of the system from the system perspective. The use case is always described from the actor (or user) perspective.
To truly understand why we don't include UI logic in use case descriptions, however, I think we'll have to take the hands-on approach. We'll work with the loan application example from my first column and you can see for yourself how a use case grows in complexity as it grows in size. In particular, we'll pay attention to the role of perspective in use case modeling. As we go along, you'll see how perspective can be made to work for you, or, if improperly applied, can work against you.
A use case model consists of a diagram and a set of descriptions that clarify the use case. A use case is a set of possible interactions in a system as its actors proceed toward a single, defined goal. The descriptions describe the functionality of the use case in the system; the diagram provides the visual roadmap of those descriptions. UML dictates standards for diagramming use cases but not for writing use case descriptions. As a result, there are numerous, sometimes competing, methods for writing use case descriptions.
The most popular method of writing use case descriptions remains true to the ideas of Ivar Jacobson, inventor of use case modeling. Jacobson's method involves a set of entry and exit criteria called pre-conditions and post-conditions respectively, and a core criteria called the flow of events. The flow of events describes one set of interactions between the actors (users or external systems) and the system being mapped out. The flow of events presents a single path through the system en route to a successful outcome. This is the heart of the use case description, but not its sum total.
Alternates and exceptions to the flow of events
In addition to describing the central flow of events, your use case description must account for interactions that occur outside the normal flow. For example, the central flow in a video-rental use case (in a very simplistic form) might be as follows:
- The video rental clerk scans the customer's membership card.
- The system acknowledges the name and current rental status of the member. An "OK to rent" status indicates that the customer may rent videos.
- The video rental clerk scans each of the videos to be rented.
- The system acknowledges that each video has been scanned by adding it to the list of outstanding videos for the customer. The system displays the current outstanding balance.
- The video rental clerk enters the amount of money received (if cash) or scans the credit card.
- The system marks the videos as rented for the default period and prints a receipt for the transaction.
But what if the customer owed a late fee from a previous rental? This would have to be paid before she could rent her current selection. The late-fee interaction would represent an exception or alternate flow. These alternates and exceptions are quite normal. In some cases they may be corrected to resume the normal flow of events, in others they will make it impossible to meet the goal. In our example, if the customer paid her late fees and the rental fee, she would achieve the goal of renting the video.
Transactions in use case modeling
The flow of events, along with its alternates and exceptions, is composed of a series of transactions. A transaction is an interaction initiated by an actor and completed when the system awaits stimulus from an actor (note that the actor that completes a transaction is not necessarily the same as the one that initiated it). Transactions allow us to partition use cases into smaller elements, grouping logic at each decision point. A decision point is the point in the description where an actor must make a decision or provide additional information.
All transactions are composed of an actor and a system interacting. You will rarely propose a system that acts without initiation, even if the initiation is merely time based. As you model your use case, you must ensure that every initiation is addressed by some sort of system response. This call and response is integral to the use case.
Transactions in sequence diagrams
Transactions are very easy to identify in sequence diagrams. In my first column, I presented a scenario with just two transactions. The first transaction was initiated when an applicant requested a new loan application. This transaction ended with the system waiting for the applicant to fill out the request and submit it. The second transaction was initiated when the applicant submitted the loan application online. It ended with the system placing a request for a credit report from the credit bureau.
Figure 1 offers a second look at the sequence diagram we created to describe this scenario, the submit loan request, and its two transactions. This diagram models the two transactions from start to finish. This is, as you will recall, a generic sequence diagram, which will allow us to add more scenarios (and thus more transactions) in the future. As we add more scenarios, we'll complete the use case, at least so far as the analysis phase of the development cycle is concerned. As we move into design, however, we might find we need to add more transactions. For example, if we choose to do screen-by-screen validation (instead of the current single validation at submission time) we'll have to add a transaction per validation.
Now take a look at Figure 1 again, paying close attention to the depiction of transactions. Start by identifying the message arrow that moves from the actor to a class or instance that appears closest to the top. As you see in the diagram below, the first one usually starts from the left. Follow the sequence of arrows until either you reach another actor or the sequence stops. When the sequence stops, it returns to the original actor. This is a transaction. You should see two complete transactions in Figure 1.
Figure 1. A partial sequence diagram of the submit loan request use case
Like most use cases, the submit loan request use case employs multiple transactions. We've diagrammed only two of them so far, but the average use case will employ somewhere between three and fifteen transactions.
In order to understand perspective with respect to transactions, let's look at how transactions behave when two systems communicate. Some software systems are actually a series of interconnected smaller systems. These smaller systems team up to provide the functionality of the whole. Each smaller system provides only a subset of the functionality of the entire system. They communicate via a set of protocols and machine interfaces, which will bring a whole new level of complexity to our use case models.
Modeling a system of interconnected systems
When you think about it, it makes sense to build large systems made up of smaller interconnected systems. You can swap out one system and replace it with another. You can build each system independently. And you can use multiple sites or vendors to complete the whole system.
The best example of such a system is your typical telephone network. One part of the telephone network provides dial-in access, another transports the voice or data, yet another provides billing services, and numerous others facilitate services such as call forwarding and voice mail. The telephone network is perhaps the largest example of a system made up of interconnected systems, and its continual operation is a testament to the effectiveness of such systems. As such, it's important that you know how to conceive and model such systems.
We'll use our familiar loan processing application to model a system of interconnected systems. Thus far we've modeled the submit loan request use case, but this use case is actually part of a larger loan processing system. The loan submission system and the credit bureau it interacts with are two systems that must cooperate to provide the data necessary to process a loan request. In real life, additional systems might be involved. For our example, however, we'll stick to just two systems. Figure 2 shows the two systems, the loan submission and the credit bureau system, and the interactions we'll focus on for the remainder of this column. (Note that Figure 2 is not a UML diagram; it is a real-world diagram, the purpose of which is to simply illustrate the systems and the interactions between them.)
Figure 2. Interactions between the two systems
Figure 3 shows a subset of the submit loan request use case as
we've diagrammed it before, from the perspective of the loan submission
system. The figure illustrates the end of our second transaction,
beginning when the applicant submits a loan request submission and
ending when the
loan submission system (CreditChecker) sends a request
to the actor representing the credit bureau (CreditBureau).
Figure 3. A subset of the system part of the loan request use case
Now, let's look at this request from the perspective of the credit
bureau system. We'll start with an actor that represents an outside system
(CreditInstitution) requesting a credit report. From the
credit bureau's perspective, the transaction begins
when the actor requests the report and ends when the credit bureau
system (CreditReporter) returns the report, as
diagrammed in Figure 4.
Figure 4. A sequence diagram of the credit bureau system
Returning to the loan submission system, we could now extend the submit
loan request use case to include the reception of the report. A new transaction
would start when the CreditReporter returned
the report and it was added to the information associated with the
application. We might then notify a loan officer (a new actor) that a new
application had arrived. This would be a third transaction
in our loan submission scenario. To create the entire use case, we
would need to add several more transactions, but we'll save that exercise
for another day.
The logic of inverse perspectives
The above diagrams illustrate two important aspects of modeling systems of interconnected systems. First, from a message-sequence perspective, we could easily model our loan submission and credit bureau systems as a single system. Figure 5 shows how the two systems would be modeled as one system in a single diagram.
Figure 5. A single-system view of the credit reporting function
This technique would work as long as we remained in the analysis stage of the development cycle. When we entered the design stage, however, the necessity of modeling the communication mechanisms between the two systems would likely overburden the single diagram. Unless we were using a communication technology such as CORBA (see Resources), we'd have to model the two systems separately once we entered the design stage. To separate the systems, we would insert actors (as seen in Figures 3 and 4) to represent the two systems to each other.
The second observation is more subtle, and is at the heart of our discussion this week: we can form a conceptual understanding of the services that one system must provide by observing the needs of the other. Or, to put it another way, we can determine the conceptual interface for each system by looking at a subset of the transaction information in the other system's use case.
Consider the second and third transactions of the loan submission
system. Specifically, let's look at the system part of the
second transaction and the actor part of the third
transaction. If we study our credit bureau at a conceptual level, the
actor part (CreditReporter) is a subset of the system
part of the loan submission system. That is, the loan submission
system use case says "the system sends a request to the credit bureau
for a copy of a credit report."
The credit bureau system use case, on the other hand, says "the credit institution actor requests a copy of a credit report." Thus, the actor part of the credit bureau transaction is a subset of the system part of the second transaction of the loan submission system. This is also true in the third transaction, where the system part of the credit bureau transaction is a subset of the actor part of the third transaction. In other words, the parts of the transactions are reversed between the two systems.
Conceptually reversing the transactions between the two systems provides a conceptual glue between the two interconnected systems. For example, we know that we will need an interface into our credit bureau that provides credit reports from the loan submission system interface that requests these reports.
How this applies to user interfaces
We don't build systems of interconnected systems all that often. We do, however, create user interfaces for most of the systems we build. We conceptualize machine interfaces between two systems by reversing the transactions of their use cases. The same is true if we replace the machine interface with a user interface.
As the examples in this article show, the user interfaces we build for our systems will be the reverse of the use case descriptions we write from the relevant actor's perspective. This is why we can't rely on the user interface perspective to write our use cases. The logic is there to create conceptual user interfaces, but the transactions will have to be reversed before they can be applied.
That said, if you've been writing UI-based use cases and have been able to deliver on that method, keep at it. Your ability to deliver is far more important than the rules laid down by methodology gurus. If, however, you've tried this method and ended up in a tangle, well, now you know why.
Next time we'll look at the different mechanisms for capturing requirements in agile processes. We will look at when and why you should use features, user stories, and use cases in a development project. See you then!
- To learn more about modeling systems of interconnected systems, see The Road to the Unified Software Development Process by Ivar Jacobson and Stefan Bylund (Cambridge University Press, 2000).
- For an in-depth introduction to Jacobson's vision of use case modeling, see Object-Oriented Software Engineering: A Use Case Driven Approach by Ivar Jacobson
(Addison Wesley, 1992).
- Read all of Granville Miller's Java Modeling articles.
- Find more Java resources on the developerWorks Java technology zone.
Granville has over a decade of experience in the object-oriented community. He is coauthor of the Advanced Use Case Modeling series and has presented tutorials at various object-oriented technology conferences worldwide. His hands-on approach to object-oriented development has been the result of his work with companies that range from startups in the very early stages to some of the most established software giants. He is currently teaching seminars, tutorials, and classes in agile processes, methodology, and Java technology, as well as mentoring and helping to deliver aggressive projects. Granville can be reached at rmiller@togethersoft.com.
Table of contents
Next steps from IBM
Rational Modeler is a free, UML 2.1 based environment that helps users to improve communication by specifying, visualizing and documenting their system, architecture and software designs using a standard graphical language.
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
