Chapter 5. Introduction to the System Use Case Modeling Process Framework
When we the begin to develop a use case model, we need to understand what we want to accomplish, what our end result will look like, and how we are going to get there. Although use case modeling can appear to be very simple at first, it becomes clear during a project that use case modeling must be performed in a disciplined, well thought-out manner. This chapter introduces a process framework for applying system use cases.
The answers to many questions may help you build a process framework:
• What are the goals of your use case modeling project?
• What outcome are you expecting from the effort?
• How do you ensure that the use case model is developed in a consistent manner across multiple analysts, customers, and users?
• How does use case modeling fit into the larger systems development picture?
• What level of formality is your organization comfortable with?
As mentioned earlier, use case modeling is an extremely flexible technique that can be customized and applied in an almost unlimited number of ways. However, with this advantage comes a challenge: use cases can be applied in almost any way you like. This means that to be successful, standards need to be in place. The project must determine the common templates to be used. It must also define the applicable models and techniques. These are placed in a document called a development case (see Appendix B). The development case is a customized description of a process tailored to fit your development project.
In Chapters 5–15, we present a use case process modeling framework and describe how it generally fits into the software system development process. In Chapter 18, we study a specific development process model, the Rational Unified Process, and show how the process framework fits into it. Then you should be able to integrate the use case process framework into other development process models.
Need for a Software Development Process
In any system development effort, a process is performed, whether the developers are aware of it or not. The developers perform a set of activities that will have a definite outcome. Problems arise when the developers are making up the process as they go along. When this occurs developers are reactive, responding to development crises without having a clear development objective or a defined path for getting there and then monitoring or adjusting the approach as needed.
Without a well-defined process, developers find it difficult if not impossible to know what they are doing and why. They have difficulty achieving consistent results across the project, monitoring the progress, and diagnosing and adjusting the process when needed.
All software development projects need to start with a process framework. A process framework is a set of activities, approaches, models, and techniques for achieving the outcome of the development effort—a working system that meets customer needs in a timely manner and within an agreed-on budget. To achieve these goals, projects must be planned and scheduled. Without a process in place, reliable scheduling is impossible. A process framework includes the following elements:
• People involved
• Models, techniques, and notations
• Automated tool support
When embarking on a use case modeling effort or any system development effort, it is important to first identify the individuals who will be involved in the effort, the models and techniques that will used, the standards to be enforced, and the process that will integrate all the elements to the development objectives. It is equally important that each member of the development team understands the value of the models and techniques that will be used.
The use case modeling process and the concepts utilized in the process are briefly described next. We then introduce a process framework for applying use case models. Some of the initial activities in the framework are presented; the definition of activities continues in subsequent chapters.
Advanced Use Case Modeling Process Framework
This section introduces the advanced use case modeling process framework and its key activities. An organization will need to modify and customize the framework for its own use. Although some use case activities naturally occur before others, the process is not meant to be linear. Developers will need to iterate throughout the process.
System Use Case Model: Modeling and Relationships
When creating use cases for a large system, particularly during an iterative development effort, the use case diagrams, descriptions, and other models will be evolving and will be refined as the use case modeling effort progresses. We refer to the complete set of diagrams and descriptions needed to represent the use cases and actors as the use case model. In addition to the use cases themselves, the use case model includes supporting text, glossaries, diagrams, and other documentation used in specifying the use cases.
The basic use case notation and concepts described in Chapter 2 provide a starting point for documenting the use case model. However, performing an extensive use case effort on a large system requires a more complete and robust set of diagrams, descriptions, and notations. In this section we introduce and describe the additional documentation used to represent use cases and their relationships with one another. Typically, use cases are first used to model the system at a conceptual level, focusing on the primary behaviors of the system, and they are refined to describe the increasing levels of detailed requirements information.
What Are System Use Cases?
This section discusses the role of use cases in the development of a single system. These use cases are referred to as system use cases. The following are key aspects of system use cases.
• During requirements analysis, a system use case models a business event, for example, a customer withdrawing funds from an ATM machine.
• A system use case is a descriptive “abstract scenario” of how an actor interacts with a system and how the system responds to the interaction.
• A system use case is a broad behavior of the system initiated by actors.
• A system use case constitutes a complete flow of events.
• A set of system use cases collectively describes system functionality.
• A use case model represents a complex reality and is developed iteratively.
A complete system use case model does not occur at once. Each use case typically goes through a process of refinement as more information is learned about the system requirements. In addition, the larger the system, the more complex are the requirements for the system. As the requirements analysis process proceeds, the use case descriptions go through a series of abstract levels, with more details added to the descriptions as more is learned about the problems.
For these reasons, a single, flat level of detail is normally insufficient to support an ongoing and evolving analysis process and also to provide the ability to robustly and effectively capture, partition, and represent the vast functionality of a large system. It is necessary, as the use case descriptions are progressively defined, to represent them at higher levels of detail. As more about the requirements is learned, more details are added to the use case descriptions. Details can be added by
• expanding information within a specific use case, that is, adding to its description,
• finding additional use cases as the requirements become clearer,
• extending the details of the use case model, through extend, include, and generalization relationships, and
• integrating multiple use cases to define larger system processes and functions and the bigger picture.
A system use case model can include the following (Figure 5-1):
• Initial system use case descriptions. Use case descriptions developed during the beginning of the requirements analysis identify and broadly describe system behaviors initiated by actors. They provide a conceptual representation of the system.
• Base system use case descriptions. Base system use case descriptions expand on the initial system use case descriptions by documenting use case behavior in greater detail. Base use cases focus on the “ideal” behaviors and paths of use cases and avoid documenting exceptions or alternatives.
• Elaborated system use case descriptions. In elaborated descriptions, details of behavior such as condition logic and alternative flows are added to the base use case descriptions.
Figure 5-1. As more requirements are captured, more detail is added to the use case descriptions
In addition to the use case descriptions, the system use case model can include other elements:
• Use case diagrams. Diagrams provide a high-level visual representation of the actors, the use cases, and the relationships between them.
• Extend, include, and generalization relationships. These relationships document extensions and commonality in use cases and also the major exception conditions and alternative flows of events that can occur in a use case. In an include relationship, a use case includes the behavior defined in another use case or behaviors that are included in multiple use cases. Extend relationships document extensions in the use case flow of events. Generalization relationships are similar to those in object modeling and document the relationship between an abstract or more general use case and more specific sub cases. (NOTE: As of UML 1.3, the extend and use relationships have been updated and replaced with the extend, include, and generalization relationships).
• Instance scenarios. These scenarios describe instances or examples of how use cases are executed. They are useful as a validation mechanism and to generate test cases.
• Analysis object models. These are models that map the use cases to the objects needed to realize the behaviors in the use case. They help to identify more detailed requirements and to map the use cases to the design. The use case to object model mapping activity can normally be performed using mapping tables, UML sequence, or collaboration diagrams.
• Dependency streams. These diagrams capture the dependencies between the various use cases and show how groups of use cases are tied together in larger process flows.
• Business function packages. When several use cases are part of a large business process, these packages group the use cases by common business functions or areas.
There are a number of reasons to describe use cases at various forms and levels of abstraction. First, as mentioned earlier, a complete use case model is not built in just one step. The model is built progressively and iteratively, as a natural result of the process of analysis, discovery, and modeling of system functionality. As more knowledge is acquired, the model is elaborated; the representations capture this progress as it occurs.
Second, the use case model has several audiences—customers, users, analysts, designers, and systems architects, to name a few. The different audiences view the use cases in different ways. Different stakeholders of the system have different viewpoints from which they examine and validate the use case model. Multiple representations help facilitate their understanding and their validation of the model. The use case model has a diverse audience, ranging from customers who are interested in functionality at a high level and users who need to validate the detailed functionality of a specific use case to the object designers who need enough information to map the use cases into an object model. A use case model must be complete and robust enough to accommodate the needs of the CIO or customer of the system who wants to review the use case diagrams and conceptual descriptions in order to understand the system concept and a system designer who wants to review the lowest level of detail in order to understand the implications of object design.
Third, multiple representations allow use cases to be more easily partitioned for development. A model containing only initial and base use case descriptions can be created for a system concept or concept of operation document. Elaborated use case descriptions and a comprehensive set of extend and include use cases can be developed during analysis activity. Incremental delivery is also supported, as entire system functionality can be modeled as a set of initial and base use case descriptions. As each increment is developed, the use cases selected for development in that increment are further refined.
Fourth, multiple use case representations are an organizational technique for adding order and understandability to a large use case model. (Further organizational techniques are discussed in Chapter 15.)
It is important to remember that use case modeling is not a linear process. Use cases are discovered, elaborated with detail, rethought, reworked, and revised as the use case modeling effort progresses.
Use Case Modeling Activities
The major activity groups in system use case modeling include the following (Figure 5-2).
Figure 5-2. Major use case activity groups
Prepare for use case modeling and determine use case approach.
• Create a glossary of system vocabulary.
• Perform a stakeholder analysis; select team members and identify involved customers and users.
• Select and customize a use case process framework.
• Select use case modeling standards, templates, and tools. Agree on granularity, voice, and style.
• Determine training and mentoring needs.
Perform initial use case modeling.
• Create initial use case diagram and/or context diagram.
• Identify the major actors.
• Discover the use cases (Initial descriptions).
• Start to identify/refine candidate business (domain) objects.
Expand on the use case model.
• Develop base use case descriptions.
• Iteratively elaborate the base use cases descriptions and determine extend, include, and generalization relationships.
• Map use cases to object models.
• Develop instance scenarios.
Organize the use cases.
• Develop business functional packages.
• Identify use case dependency streams.
• Organize the use cases by stakeholder views.
• Refactor the use case model.
Ongoing use case management.
• Validate use case model with users.
• Define and execute training plan.
• Track ongoing use case modeling progress.
• Update and customize framework, based on stakeholder feedback.
The Interesting Issue box on page 69 discusses the dangers and challenges of mixing system use case definition and GUI design too early in requirements processing. The Interesting Issue box “Is There Only One Right Way to Model with Use Cases?” (page 70) talks about how different approaches can be used when performing use case modeling.
Creating or Customizing a Process Framework for a Specific Project
When a project is first conceived, the developers should select, refine, or create a process framework for the project. A number of commercial processes, such as the Rational Unified Process, are available for use and refinement on an object-oriented project.
Process frameworks normally need to be adjusted based on a number of project-specific factors:
• Size of the project. Large projects typically require much more process and guidance then smaller projects, where the overhead of following a rigorous process can sometimes outweigh the benefits.
• Domain. Although all software development processes involve many of the same key activities—analysis, design, and testing, for example—the specifics can vary greatly depending on whether the system is a business system, a real-time military system, or a systems application such as a compiler or operating system.
• Use of incremental or iterative development. When using an iterative or incremental development approach, the leaders of the project need to clearly think out its strategy for tracking progress, revisiting deliverables, and so on.
• Experience of the team. An inexperienced development team will typically need more structure and guidelines than an experienced one.
This generic use case process framework is meant only for system use case modeling and should be refined and modified into the overall systems development process (Figure 5-3).
Figure 5-3. Generic use case modeling system development
Almost every systems development effort varies in its specifics, so any use case process framework almost always needs to be customized. As Ivar Jacobson [1998] has stated, “There is NO universal process.” We have not seen a process framework for any systems development effort that did not need some form of adjustment or customization. However, it’s a lot easier to customize an existing framework that is based on project experience than to develop your own from scratch.
When customizing a use case modeling framework, the framework’s process, activities, and tools can be adjusted. An existing process, whether it is commercial or developed in-house for internal use, is simply a starting point. A single specific use case framework can be customized or multiple frameworks can be combined to fit in with the larger development process. Figure 5-4 shows three dimensions in which a framework can be tailored. First, the specific activities to be performed and models, notations, and tools can be customized. Second, the relation and dependencies of activities and models can be adjusted. In addition, the framework itself can be fitted into the larger development process. Finally, the organizational cultures and issues need to be considered.
Figure 5-4. Tailoring dimensions of the use case process framework
Conclusion
This chapter outlines a use case process framework, with a clear definition of goals, objectives, and considerations. Use case modeling for a large iterative development requires multiple models and a well-thought-out process for applying the models. Use case modeling may seem simple at first, and for small projects it can be. However, for large efforts, the activities, models, and notations, as well as the stakeholders involved, need to be clearly defined in the use case process framework, and the framework must fit into the larger development picture.