In this article, we describe an approach integrating use case modeling and feature modeling to support the description and maintenance of a common and complete use case model for an entire family of systems. This approach, referred to as PLUSS (Product Line Use case modeling for Systems and Software engineering), is currently applied in several large-scale defense projects within BAE Systems Hägglunds AB.
Traditional use case modeling targets single-system development and provides poor support for variability management. To support effective variability management a single common system family model should be enforced. Variant information must be kept and maintained in one place. In PLUSS, we follow the same ideas as proposed by Griss et al. [6] and combine use case modeling with feature modeling (see Table 1).
FODA-like feature models give an overview of the features of a system family and their interrelationships [10]. Features can then be modeled by groups of use cases. However, there may also be variant use cases. We distinguish four kinds of variations in use case models for product families [2]:
- Use cases might or might not be included in a particular product.
- Certain scenarios of an included use case might be excluded from a particular product.
- The flow of events within an included scenario might vary.
- Cross-cutting aspects that can affect several use cases on several levels. For example, the existence of different sets of use case actors (system users) in different products.
In PLUSS, all such variations are managed using a common feature model, that is, the feature model provides a total overview of all variants within a product line use case model. A particular set of features for a specific product within a product line, therefore directly corresponds to a particular set of concrete use cases for that product. We accomplish this by relating use cases, use case scenarios, and steps within use case scenarios to features of appropriate types in the feature model (see Figure 1 for an example). To support cross-cutting variability, we include textual parameters into our use case descriptions. These parameters, which can be single-valued or multi-valued as illustrated by “$PARAM_1” and “$PARAM_2” in Figure 1, are represented in the feature model as well. If a product includes a use case description with such a parameter, it must also instantiate that parameter by selecting one (or several) feature value entities from the corresponding “parametric feature” in the feature model.
Traceability and Reuse
For each use case, there are one or more use case realizations describing how different design elements collaborate to realize a specific use case goal (see Figure 2). In PLUSS, we utilize this “built-in” traceability by maintaining use case realizations together with their corresponding product line use case models. By selecting particular use cases, scenarios, and scenario steps for a specific product one also determines the architectural elements responsible for the corresponding functionality. This leads to an improved reuse infrastructure.
By selecting particular use cases, scenarios, and scenario steps for a specific product one also determines the architectural elements responsible for the corresponding functionality.
Product derivation is basically done by first adding new requirements to the model(s) and then using the (possibly updated) feature model to choose among its variants. We use the selected features as a filter to view only the relevant parts of the full product line model. This yields three types of reports: A Use Case Model Survey, Use Case Specifications, and Use Case Realizations. The use case model survey gives an overview of all use cases for the product. For each use case in this survey, there is a use case specification describing black-box system level scenarios for this use case and use case realizations describing the corresponding white-box realizations on subsystem level (see [3] for tool support).
Change Cases and Maintenance
Change cases [1] are basically use cases that specify anticipated future changes to a system. They provide a relation “impact link” that supports traceability to affected use cases, if the change case is realized. Modeling change cases allows product line designers to plan for and, more effectively, accommodate anticipated future requirements in a domain. In PLUSS, we utilize change cases as a means for developing Change Requests (CR) and Engineering Change Proposals (ECP) to our product line. New requirements are modeled as change cases to (1) provide an overview of the current delta between the original and the current model, and (2) to provide stronger support for product line change impact analysis. However, once accepted for implementation in a product within the product line, these change cases are transformed to use cases as illustrated in Figure 3.
Experience
Initially, PLUSS was used to reengineer a subsystem product line for an onboard vehicle information system resulting in a product line model containing approximately 200 features and 40 (parameterized) use cases. A case study after the first two delivered products revealed very positive results (see [2], summarized in Table 2). Since then several new products have been added to this model, and PLUSS is now also used to model other product lines within the organization.
Developing and maintaining a common and complete model for an entire product line requires more formalism in an organization, compared to the traditional “cloning” approach.
PLUSS is a relatively simple extension to “standard” use case modeling and fits very well within the Unified Process framework. This implied low adoption costs, since use case modeling and a RUP-based process were already in place at our company. It was furthermore relatively easy to extend our single-system CASE tool environment, consisting of Telelogic DOORS and IBM-Rational Rose, to support some parts of PLUSS (see [3]).
We would like to stress two other lessons learned from this work. First, developing and maintaining a common and complete model for an entire product line requires more formalism in an organization, compared to the traditional “cloning” approach. The simple reason for this is that several products are managed at the same time instead of separately. Secondly, adopting such an approach may lead to resistance from some product development teams. They no longer “own” the complete product requirements documentation, since they are a part of the product line core assets base. This reduces the degrees of freedom for the product development teams, which, however, is a desirable effect from a management point of view to support effective reuse.
Figures
Figure 1. An example of the relationship between features and use cases.
Figure 2. An example of the notation used for describing (a): use case scenarios (system level), and (b): use case realizations (sub-system level).
Join the Discussion (0)
Become a Member or Sign In to Post a Comment