Discussion of the FODA Method

manual examination. This situation was a primary reason for building a prototype automated features tool to represent the feature model and support consistency and completeness checking. The manual methods were insufficient to handle a set of little more than 100 fea-tures, and would clearly be inadequate to the task of modelling a larger domain.

Representing the results of a domain analysis process is primarily a task of representing a large amount of knowledge, and providing facilities so that the user can access that knowl-edge quickly and easily. The goal of domain analysis tool support is to offer an integrated environment for collecting and retrieving the domain model and architectures. The current set of manual and independent semi-automated methods does not meet this goal. It has, however, clearly pointed out the problem which must be addressed, and provides a basis for working on the problem.

The sample analysis used Statemate to prototype a tool that could take a consistent set of features produced by the automated features tool and support the functional modelling of the domain. Statemate has provided valuable support to the domain analysis, but also has several limitations. Among the strengths of the Statemate tool are:

•It is a good analysis tool.

•It supports parameterization.

•It is a production-quality tool.

Some of the weaknesses of the Statemate tool are:

•It is not scalable without tailoring.

•The transitions/conditionals hide commonality.

•It is difficult to transition due to the cost and training required.

Statemate can also serve as a means of establishing requirements for domain analysis tools as discussed in Section 8.2.

8.2. Future Directions

8.2.1. Near-Term

8.2.1.1. Formalization of Features

The FODA method does not apply formal techniques in the specification of features. The specification of features is made informally in English text, which can result in ambiguity and inconsistency. For example, features from the window manager domain such as constrainedMoveandzapEffectcould have been specified more precisely using a for-mal specification technique. The project applied an algebraic specification technique to specify the concept of stacking order in the window manager domain.16 However, this effort was not expanded to cover the entire model.

16This technique is not discussed in this report.

8.2.1.2. Formalization of Issues/Decisions

The FODA method records issues related to each decision point of the feature model to help users make selections of both optional and alternative features. However, it does not pro-vide a model showing how these issues are related. For example, in the case of automobile features in Figure 5-1, the issue of operating cost is related to maintenance cost and fuel efficiency, and to help users make decisions this relationship must be captured in the model with quantitative values. (One way of implementing this feature is to define issues as fea-ture attributes; the issue model would be used to define relationships between these attri-butes, i.e., issues.)

Also, a customer often has a set of conflicting issues. For example, if one wants to buy a car with good acceleration and low fuel consumption, he identifies the requirements (i.e., issues) that are contradictory and a compromise decision must be made. While this type of situation is resolved on a regular basis without automated support, more complex sets of conflicting issues are not so easily decided. Automated assistance is needed to identify these conflicting issues and resolve them to make an optimal decision.

8.2.1.3. Tool Support for Domain Analysis

The feasibility study determined the need for tools to support both the process of domain analysis and the process by which the products of domain analysis support software devel-opment. These tools are needed to deal with the volume and complexity of information gathered during the domain analysis and the presentation of that information in specific domain analysis products. Tools are also required to provide a user with an understanding of the domain and to support the user/implementor interaction in developing a new system within the domain. Domain analysis tools will also be used to support the development and application of reusable software.

The study established four levels of tool support, ranging from manual methods to those that are specifically intended to support domain analysis. Figure 8-1 illustrates the successive levels of support and provides examples of each. The first level provides only a database of information that the user must handle through manual means to derive any new results.

The second level takes the data from the first level and automates part of the derivation process. For example, the automated features tool (see Section 7.3.2.6) checks consis-tency between features and the Statemate-supported simulation of the functional model.

The third level, that of integrated tools, takes general-purpose tools that may be used in an informal way at the second level and incorporates their use into the method. Tools at the fourth level are those specifically developed or tailored to support the specific needs of domain analysis.

One task in future domain analysis methods investigation will be to further integrate tool support into the domain analysis method and produce requirements for specific domain analysis support tools. This investigation will determine which of the four approaches pro-vides the best support for the FODA method and which can be most easily transitioned.

The investigation will continue to work in well established domains to refine these require-ments in a prototype tool.

CMU/SEI-90-TR-21 89