Examine existing Use Cases, and build a Use Case diagram. Create Use Cases to model the scenario of a customer making a reservation.

In this module, begin using Use Cases to model the business scenarios. In TOGAF, this tutorial would be considered part of phase C. Information Systems Architectures.

On a Use Case diagram, you model Use Cases that represent the scenarios in your business, and the external actors which interact with those scenarios. The scenarios are described using text or with a sequence of steps. Use Case modeling is considered a problem-driven approach to object-oriented analysis because the designer gives primary consideration to the problem at hand, and not to the relationship between objects (as in the data-driven approach).

Modeling with Use Cases can illuminate the need for objects in your system. When the system has been described in terms of its scenarios, you can examine the text or the steps defining each scenario and determine necessary objects.

When you build a new system, you model scenarios that describe the way the business should work. When redesigning an existing system, you choose to model first the scenarios of the current system, and then the scenarios for how the system should work.

Use Cases are also used in testing a design. When the design is complete, you can walk through the steps of the scenarios to determine if the design enables the scenarios to occur as planned.

Where do Use Cases fit with the process and functional modeling in enterprise and business diagrams? They differ in approach. If you are strictly using UML to model your business, you can use Use Cases to create contextual models. This modelling includes:

You might prefer to use the techniques presented in previous tutorials, such as using process chart diagrams to understand business events, process flows, results, and functions that these processes create for contextual and conceptual business modeling. When you create these diagrams you have the option of using Use Cases as a bridge into object-oriented analysis and design of the business systems. You might create a Use Case corresponding to every low-level process (Elementary Business Process) on the Process Chart diagram, then use the techniques of UML to examine the Use Cases to find objects. Although this introduces a second set of diagrams representing similar ideas (and thus added modeling maintenance, since a change to a business process would have to be represented in both places), it can provide a clear bridge between conceptual business modeling and system modeling with UML.

A third alternative would be to skip UML Use Cases entirely, and use the Process Charts to drive the next levels of application design (that is, creating Sequence and Class diagrams).

After completing the lessons in this module you will know how to:

This module should take approximately 20 minutes to complete.

To complete this module, you will need to have the Tutorial encyclopedia open. If you need directions on how to open prebuilt encyclopedias, or this encyclopedia is not attached to your server, refer to the Introduction section of this module.

Organize your project into packages to reflect the different components and stages of development of your business.

Create a model of a Use Case to show the relationships between actors and packages.

Elaborate your Use Case scenario by creating a child Use Case diagram.

Define the actors and define a Use Case scenario using steps.

Identify what is involved in your Use Case scenario by creating an Includes Relationship sub-scenario.

Extend a Use Case to add alternative courses of action to a Use Case scenario.

Modify properties in the USRPROPS.TXT file by adding a new definition file and then making the new definition the property of an existing Use Case definition.

Attach your Business Requirements, (created in the previous lesson), to the Use Case that satisfies it.