Use Case Driven Modeling

Use Case Driven Modeling

The Unified Modeling Language User Guide (UML) defines a use case as follows:

A use case specifies the behavior of a system or a part of the system and is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor.

A use case is an outside view of the system as seen by the entities interacting with the use case. It is used for capturing the requirements of a system. A use case is not atomic; a use case representing a complex system behavior can be further decomposed into more use cases. A use case is essential for creating a common understanding of the system behavior between the business domain experts, the application architect, and developers, without specifying how that behavior is implemented. During design, a use case is realized by a set of related objects working together to deliver the behavior prescribed by the use case. Models created during design must be able to map back to the requirements by their ability to satisfy each use case within the problem domain. The use cases therefore help validate the architecture. In an iterative design and development process, use cases enable catching of deviation from requirements early in the life cycle; all models and project artifacts are synchronized for accurately reflecting the purpose of the system all throughout the project life cycle. As such, risks are identified early in the process, therefore preventing major rework later.

Use cases document the system and form the bases of test cases for user acceptance, integration, regression, and system tests. This approach has built-in traceability because all design, development, and testing is performed based on use case scenarios. The use cases become a contract between the business units and the IT organization. By employing incremental and iterative approaches, this contract is enforced throughout the development life cycle by verifying intermediate artifacts against the behavior prescribed by the use cases. The use case model is central to all analysis and design artifacts, and for project planning.


This book consistently strives to live by the word "practical" in its name. Therefore, every concept presented in this book is explained using the fictitious GreaterCause application. The use cases discussed in this chapter will lay the foundation for understanding the problem domain. The use cases will be subsequently realized using architecture and design artifacts explained in the rest of the book.

Subsequent sections in this chapter explain what, why, when, and how to capture system requirements for the sample application. In this chapter, the following sections denote the artifacts created for the sample application:

  • GreaterCause System Definition

  • GreaterCause Context Diagrams and Actors

  • GreaterCause Risk Factors

  • GreaterCause Dependencies

  • GreaterCause Use Case Packages

  • GreaterCause Use Case Summary

Familiarity with the preceding structure will assist you in distinguishing the project artifacts from the commentary that surrounds the artifacts.

Defining the Problem Domain

To promote understanding of the problem domain, we ask ourselves several questions, some of which can be stated as follows:

  • What business needs will the software try to solve?

  • Who are the users of the system?

  • What functionality will be supported by the system?

  • What are the interactions between different subsystems?

  • What components in the problem domain can be provided by a third party as off-the-shelf components?

  • What components of the system can be isolated to form reusable, self-contained subsystems?

The answers to these and myriad other questions help us understand the solution space. We will be gradually answering these questions as we proceed through the book.

The first step in understanding the problem domain is to create a project description. A project description should explain the purpose of the project. It must be concise, and it should quickly demonstrate the business objective. You will be surprised how many different perspectives evolve at this time from different stakeholders. At this stage of the project, most stakeholders are concerned with return on investment. A project description is therefore the first consensus point between stakeholders because it clearly states the objectives of the new system.


Before you begin to write the system description, you may find it helpful to define domain-specific terms for your audience; this will establish a common vocabulary for communication. You may optionally provide an operational model for added clarification, as shown in Figure 1-1.

click to expand
Figure 1-1: GreaterCause operational model

GreaterCause System Definition

The following terminology is consistently used in defining the problem domain.

  • GreaterCause is a philanthropic application that is hosted at a central location.

  • is the domain name of the site where the GreaterCause application is accessible as a hosted service. For brevity, the term "site" will refer to the site.

  • Portal is a personalized single point of access for business and consumer services.

  • Portal-Domain is the domain that hosts a consumer portal or a corporate intranet.

  • Portal-Alliance is formed as a result of portals providing a pass-through or gateway component, also called a portlet, on the portal page for redirecting portal users to the site.

  • NPO is a non-profit organization that registers with site for soliciting charitable contributions from prospective donors.

The domain is responsible for hosting the GreaterCause charitable-giving application at a central location. The site is accessible to the donors via various consumer portals and corporate intranets.

Portal-providers create an alliance (i.e. a service contract) with GreaterCause to procure the GreaterCause services for their user base. An agreement between a portal-provider and GreaterCause to serve the portal's users is termed Portal-Alliance. Each portal-alliance has an associated administrator ID and password using which the portal-alliance Administrator (an employee of the portal provider, or its designate) can maintain the portal-related profile information. The portal-provider interposes itself as a gatekeeper to the GreaterCause application by using a portion of the portal's real estate to provide an intelligent gateway or pass-through to the GreaterCause site for their subscriber base. The GreaterCause pass-through is available as a portlet. This portlet is aggregated into the portal view of the partnering portal-domains.

Non-profit organizations (NPOs) register with GreaterCause to list themselves in the GreaterCause database for receiving charitable contributions (i.e. donations) from the visitors of the site. Each registered NPO is provided with an administrator ID and password using which the NPO administrator can maintain its related profile information.

Although, visitors can donate to any of the available charities (i.e. NPOs), a portal-provider can influence the decision of a donor in the selection of a preferred charity; this is done by campaigning for the preferred NPOs. Portal-alliance administrators have the ability to log in to the site with their administrator ID and create campaigns for non-profit organizations at both the national and regional level. These portal-alliance–specific campaigns for preferred NPOs are stored at the site and subsequently featured by the portal-domains on their respective portal-page. The list of featured non-profit organizations (featured-NPOs), created by the portal-alliance administrator in the database, is provided via a web service to each portal-domain; this list is subsequently displayed by the portlet hosted within the portal-page. Prospective donors visiting the portals are provided with the option to donate to either the featured non-profit organizations, or pass through directly to the site for searching and donating to a non-profit organization of the donor's choice.

Once a portal-user is redirected to the site by the portal-provider, the GreaterCause service, as viewed by a portal-user, is customizable by portal-alliance administrators for preserving the branding and navigation structure of their respective portal-domains. The portal-domain, before redirecting the portal-user to, is responsible for authenticating the portal-user (a.ka. the donor). The portal-domain and the site mutually authenticate before redirecting the donors. Donor's registration information is provided by the portal-domain to during the redirection process.

All transaction history is logged using the donor's registration ID and portal-domain affiliation. Donors have the ability to view their history of donations for the current and previous year.


The description of the system provides a vocabulary that consists of real-world objects. Use case names are derived from this vocabulary and tend to express the behavior of the system in short, present-tense verb phrases in active voice; the use case being named must represent a reasonably atomic behavior of the system. In the use case context, a client is an external actor to the use case—which could be a human, another software system, or an asynchronous message. Therefore, a use case name is most effective when expressed from the perspective of the user.