The Life Cycle of a Use Case
- The Software Development Live Cycle
- The Authoring Live Cycle
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
So far, we have seen the basic concepts behind the use-case modeling approach to eliciting and capturing software requirements and looked at how to get started in applying them. Before we look at the mechanics of authoring full use-case descriptions, we need to have a better understanding of the life cycle of a use case and how well-formed, good quality use cases can drive and facilitate the other, downstream software development activities. We also need to put what we have learned into a broader perspective with regard to software development and team working.
Use cases have a complex life cycle—they undergo a series of transformations as they mature through a number of development stages, from discovery to implementation and eventually to user acceptance. One way that this life cycle manifests itself is in the style and form adopted for the use-case descriptions. To speak of a single way of representing a use case is to miss the point—there are different presentation approaches and styles that are useful at different points in the use case's evolution. There is no one single form that is "better" in the absolute sense; they all play a role. This is why you will often see use cases expressed in different formats by different authors in different use-case texts.
Use cases also play a broader role, outside of the requirements space, in driving the analysis, design, implementation, and testing of the system. This is why you will also read about use cases being realized in design and tested by testers. Sometimes the use cases are so embedded in the design process of the system that the impression is given that the use cases are a development artifact rather than a requirements one. This misconception often leads to developers trying to manipulate the use-case model in a misguided attempt to design the system using use cases.
To fully understand the role and purpose of use cases, and consequently the most appropriate form to use, we need to look at the life cycle of a use case from a number of different but complementary perspectives:
Software development: how the use case is reflected throughout the full software development life cycle
Use-case authoring: how the use case and its description evolves through the authoring process
Team working: the activities involved in creating a use case model and how these impact on team and individual working practices
The Software Development Live Cycle
As well as facilitating the elicitation, organization, and documentation of requirements, use cases can play a more central and significant role in the software development life cycle. This is especially true for many of the object-oriented and iterative development processes for which use cases are recommended.
From a traditional object-oriented system model, it's often difficult to tell how a system does what it's supposed to do. This difficulty stems from the lack of a "red thread" through the system when it performs certain tasks.1 Use cases can provide that thread because they define the behavior performed by a system. Use cases are not part of traditional object orientation, but over time their importance to object-oriented methods has become ever more apparent. This is further emphasized by the fact that use cases are part of the Unified Modeling Language.
In fact, many software development processes, including the Rational Unified Process, describe themselves as "use-case driven."2 When a process employs a "use-case driven approach" it means that the use cases defined for a system are the basis for the entire development process. In these cases the life cycle of the use case continues beyond its authoring to cover activities such as analysis, design, implementation, and testing. This life cycle is shown, in simplified form, in Figure 6-1. Figure 6-1 is arranged to emphasize the three main applications for the use cases:
)
Figure 6-1 The software development life
cycle*
Requirements: the identification, authoring and agreement of the use cases and their descriptions for use as a requirement specification. This is the focus of this book.
Development: the analysis, design, and implementation of a system based on the use cases. This topic is outside the scope of this book.3
Testing: the use-case-based verification and acceptance of the system produced. Again, the details of how to undertake use-case-based testing is outside the scope of this book.
It is this ability of use cases to unify the development activities that makes them such a powerful tool for the planning and tracking of software development projects.4 To fully understand the power of use cases, it is worth considering this life cycle in a little more detail. Use cases can play a part in the majority of the disciplines directly associated with software development.
Requirements: The use-case model is the result of the requirements discipline. Requirements work matures the use cases through the first three states, from Identified to Agreed. It also evolves the glossary, or domain model, that defines the terminology used by the use cases and the Supplementary Specification that contains the systemwide requirements not captured by the use-case model.
Analysis and Design: Use cases are realized in analysis and design models. Use-case realizations are created that describe how the use cases are performed in terms of interacting objects in the model. This model describes, in terms of subsystems and objects, the different parts of the implemented system and how the parts need to interact to perform the use cases. Analysis and design of the use cases matures them through the states of Analyzed and Designed. These states do not change the description of the use cases, but indicate that the use cases have been realized in the analysis and design of the system.
Implementation (also known as code and unit test or code and build): During implementation, the design model is the implementation speci-fication. Because use cases are the basis for the design model, they are implemented in terms of design classes. Once the code has been written to enable a use case to be executed, it can be considered to be in the Implemented state.
Testing: During testing, the use cases constitute the basis for identifying test cases and test procedures; that is, the system is verified by performing each use case. When the tests related to a use case have been successfully passed by the system, the use case can be considered to be in the Verified state. The Accepted state is reached when a version of the system that implements the use case passes independent user-acceptance testing. Note: If the system is being developed in an incremental fashion, the use cases need to be verified for each release that implements them.
These relationships are directly reflected in the life cycle of the use case just described and are illustrated in Figure 6-2.
Figure 6-2 The use-case model and its relationship to the other software development models
Use cases can also help with the supporting disciplines, although these do not impact upon the life cycle of the use cases themselves:
Project Management: In the project management discipline, use cases are used as a basis for planning and tracking the progress of the development project. This is particularly true for iterative development where use cases are often the primary planning mechanism.
Deployment: In the deployment discipline, use cases are the foundation for what is described in user's manuals. Use cases can also be used to define how to order units of the product. For example, a customer could order a system configured with a particular mix of use cases.
Although primarily a requirement-capture technique, use cases have a significant role to play in the ongoing planning, control, development, and testing of the system. It is this unification of the software development process that makes use cases such a powerful technique. To get the full benefit of using use cases, they should be placed at the heart of all the software development and project planning activities.5