Abstract
The majority of the present software systems, such as those that run on automatic banking machines (ABMs), on mobile devices, and on the Web, are interactive in nature. Therefore, it is critical to precisely understand, identify, and document the services that an interactive software system will provide from the viewpoint of its potential users. A large and important class of models that these services encapsulate is use cases (Jacobson, Christerson, Jonsson, & Övergaard, 1992). In the last few years, use cases have become indispensable as means for behavioral modeling of interactive software systems. They play a crucial role in various software development activities, including estimating development cost (Anda, 2003), eliciting behavioral requirements, and defining test cases. It is well known that addressing quality early is crucial to avoid the propagation of problems to later artifacts (Moody, 2005). With the increasing deployment of use cases as early artifacts in software process environments, the question of how these models should be developed so as to attain high quality arises. In response, this article focuses on the use case modeling process (the act of constructing use case models) and, based on the notion of patterns (Appleton, 1997), proposes a systematic approach towards the development of use case models. The rest of the article is organized as follows. The background and related work necessary for the discussion that follows is outlined. This is followed by the presentation of a pattern-oriented use case modeling process for systematically addressing the semiotic quality of use case models in a feasible manner. Next, challenges and directions for future research are outlined, and finally, concluding remarks are given.
TopBackground
In this section, the terminology necessary for the discussion that follows is presented and the significance of quality in the development of use case models is briefly reviewed.
A Primer on Use Case Models
A use case models the behavior of a software system, which yields an observable result of value to an actor of the system (Jacobson et al., 1992). In doing so, a use case intends to capture typical interactions between the actors and the software system being built. There can be multiple use cases of a system and they can be related. The use cases can be classified into analysis use cases (those addressing the problem domain) and synthesis use cases (those addressing the solution domain). There are three possible types of (binary and non-reflexive) relationships among use cases: “include,” “extend,” and “generalization.”
An actor is an external entity that interacts with each instance of a use case. An actor could be a (human) user or another program. Each actor plays a unique role with respect to a use case from the viewpoint of the system. There can be multiple actors of a system, and they can also be related. The actors can be classified into primary actors (those initiating a use case) and secondary actors (those supporting the goal of a primary actor). There is one possible type of (binary and non-reflexive) relationship among actors: “generalization.”
A use case is an abstraction of the real-world use of a system. A scenario is a concrete realization or instance of a use case; it can be classified as either normal or non-normal (including alternates and exceptions).
The system boundary is a means to illustrate the separation of actors and use cases. The set of all actors and use cases describing the complete usage of a system is known as the system’s use case model.
There are two common means of representing use cases: as structured text and as a graphic. Each means of representation has its own advantages and limitations (Jacobson, 2003); a detailed discussion of this issue is beyond the scope of this article.
The Unified Modeling Language (UML) (Booch, Jacobson, & Rumbaugh, 2005) is a standard language for modeling the structure and behavior of object-oriented software systems. UML provides explicit support for use case models (Bittner & Spence, 2003): the Use Case Diagram is a commonly used UML diagram type to graphically represent use case models, the Activity Diagram is used to represent the sequential order in which use cases are executed, and the Sequence Diagram is used to represent scenarios.
Key Terms in this Chapter
Semiotics: The field of study of signs and the communicative properties of their representations.
Use Case Model Quality: The totality of characteristics of a use case model that bear on its ability to satisfy stated and implied needs.
Pattern: A proven solution to a recurring problem in a given context.
Software Engineering: A discipline that advocates a systematic approach of developing high-quality software on a large scale while taking into account the factors of sustainability and longevity, as well as organizational constraints of time and resources.
Refactoring: A structural transformation that provides a systematic way of eradicating the undesirable(s) from an artifact while preserving its behavioral semantics.
Use Case Modeling Process: A set of activities and practices that are used to develop and maintain a use case model.
Use Case Model: A behavioral model that captures typical interactions between actors and the software system under development.