Java Modeling: UML workbooks, part 3rd

Requirements gathering is an indispensable step in any successful software development cycle. Although there are a number of requirements collection methods, the most common method is use case modeling. In the previous two columns, we have completed part of the work of associating sequence diagrams with use case modeling. This time I will talk more about the theory behind the method and also add some of your modeling vocabulary.

In this discussion, I am more concerned with clarifying the relationship between user interfaces, system interfaces, and use case descriptions. Because most of the systems that are built will be designed to be interactive with adult machines, it is tempting to design use-case descriptions to start with a user interface. However, the inclusion of user interface logic in use cases is often considered a bad form. A simple explanation for this argument is that the user interface provides a systematic overview of the system perspective. A use case is always described as a contributor (or user) perspective.

To really understand why we don't include UI logic in use-case descriptions, I think we have to use the hands-on approach anyway. We will use the example of the loan request in my first column, and you will see how the use case becomes more complex as the size increases. In particular, we want to pay attention to the role of perspective in use case modeling. As we drill down, you'll see how the perspective is used to work for you, or how it hinders you from working if it is applied incorrectly.

What is a use case model?

A use case model consists of a chart and a set of descriptions that illustrate the use case. A use case is a set of possible interactions within a system in which the participants move toward the same defined goal. These descriptions describe the functionality of the use case in the system; This chart provides a visual roadmap for these descriptions. UML sets the standard for building use case diagrams, but not for writing use case descriptions. The result is a number of ways to write use case descriptions, which sometimes compete with each other.

The most popular way to write use case descriptions is the idea of Ivar Jacobson (the inventor of Use case modeling). The Jacobson approach involves a series of entry and exit criteria, called preconditions and post conditions, and a core guideline called event flow. This event flow describes the interaction between a series of participants (user or external System) and the system being developed. This event flow represents a single path through the system leading to a successful output. This is the core part of the use case description, but not all.

Alternating and exceptions of event streams

In addition to describing the central event flow, the use case description must describe the interactions that occur outside of the normal event stream. For example, the main event flow for a videotape rental use case (in simple cases) can be expressed as follows:

The video rental store clerk scans the customer's membership card.

The system obtains the member name and his current lease condition. A "Allow lease" status means that the customer can rent a videotape.

The video rental store clerk scanned every tape that was rented.

By scanning each videotape, the system adds a video that can be rented to the user's visible list and displays a list of currently available videos.

The video rental store clerk enters the amount of money to be charged (if it is in cash) or scans the credit card.

The system marks this videotape as a receipt that has been leased for a certain period of time and is printing the transaction.

But what if the customer owes a late fee on the last loan? She will have to pay off the overdue fee before she can rent her selected tapes again. The interaction of overdue fees is expressed as an alternating flow or an exception stream. The alternation and exceptions of the event stream are normal. In some cases, they can be corrected to restart the normal flow of events, and in other cases they will not reach the target. In our example, if the customer paid the overdue fee and the rent, she would have to continue to rent the tape.

Transaction processing in use-case modeling

Along with its alternation and exceptions, the event flow is made up of a series of transactions. Transactions are initiated by the participant, and the interaction is completed when the system waits for a trigger signal from the participant (note that the participant who completes the transaction is not necessarily the participant who initiated the transaction). Transaction processing allows us to split the use cases into smaller elements and group the logic at each decision point. The decision point is the point in the description where the participant must make a decision or provide additional information.

All transactions are composed of a participant and a system interaction. You will rarely need to plan a system that does not start, even if it is only based on time. When building a use case model, you must ensure that each startup is accessed by some type of system response. This invocation and response is complete for use cases.