FODA Context Analysis

These are the domains for which the results of previous domain analyses exist as stan-dards, reusable components, and/or domain models. These sub-domains should be identi-fied as lower-level domains in the structure diagram and as external entities in the data flow diagrams. Standards or other domain analyses results that apply to the external entities should be identified in the diagram.

For each entity in the context model, the following information should be included in the document.

•Name of the entity (an object on the diagram).

•Description of the function for a functional entity or description of the contents for a data entity.

•Applicable standards and/or reusable components.

•Description of variability, including the range, frequency, and binding time (i.e., compile-time, activation-time, and runtime) of the variation (see Section 5.1.2 for details of feature binding times).

•Other items describing the attributes of the entity.

•Source for the information or for additional information.

Other information which would be appropriate to include in the context model would be the applicable or related features from the feature model produced during the domain modelling phase (see Section 5.1). The incorporation of this information into the context model implies either an "iterative" or a parallel approach to the context analysis and domain modelling phases, since in a strictly sequential approach the feature model would not be available to the context analysis (it is developed in the next phase of the analysis). The feature model information may be useful in determining the scope of the analysis.

4.3. Model Usage

One of the necessary conditions for building reusable software is an understanding of the different contexts in which the reusable software is to be incorporated or operated. This un-derstanding of the extent of contextual differences, and when and how frequently the con-text changes, will help software developers decide if software that meets the requirements can be built and, if so, what to parameterize and how to structure software so that it can be adapted to different contexts as needed. For example, in an environment where there are many different types of terminals, the user interface part of the software should be built so that it can handle different terminals without modification. In order to be able to build com-5

mon user interface software, the commonality and differences of terminals (to abstract and define common interfaces) and their usages (to build common utilities) must be understood.

The understanding of contextual variations will help rescope the domain. If there is a high degree of variation in context and the contextual differences cannot be abstracted away, it

5Precisely this capability is provided by the UNIX "curses" and "termcap" facilities.

32 CMU/SEI-90-TR-21

might indicate either that there is no commonality, or that the domain needs to be rescoped to a narrower domain.

The context model defines the scope of a domain analysis. Other subsequent analysis acti-vities, such as feature modeling, functional modelling, entity-relationship modelling, and ar-chitecture modelling, are all performed within the scope defined in the context diagram. The data-flow context diagram is used as the starting point in the functional modelling.

4.4. Process and Guidelines

To yield domain products that can be exploited in other applications, the scope of a domain should be decided considering: (1) the commonality of the domain in existing systems, (2) the availability of information on the domain and domain expertise, (3) the expected usages of the domain products, and (4) the project resources and constraints. Keeping these fac-tors in mind, the activities for context analysis and domain scoping are identified as follows:

1. Make an initial "cut" of the target domain and the domain boundary. (It is as-sumed that a candidate domain for context analysis is already selected.) Identify the existing applications in the domain or applications using the domain. Identify information sources and any previous works on the domain including domain analysis products, standards, and books and technical papers.

2. For each application identified for the analysis, describe the context of the candidate domain in terms of structure diagrams and data-flow diagrams.

Verify that the domain has a clear physical boundary within the application. If there are any previous domain analysis results or standards, determine if they address each application adequately; record problems, if any.

3. Understand the usage of the target domain, any recent technical develop-ments that will affect the domain, and any future plans or requiredevelop-ments.

4. Analyze the variability of the usages and the contexts of each use.

a. Based on the features of applications in the domain, begin the defini-tion of a feature model (See Secdefini-tion 5.1 on the feature model).6

b. Identify the environmental differences (i.e., operating environments).

c. Identify any assumptions (sub-domains and standards) on which the target domain is based.

d. Construct a common model by classifying specifics of the contexts into general categories so that each context can be defined as an instan-tiation of the common model.

5. Evaluate the model against the applications used in the analysis and incor-porate the variability information (i.e., how the common model can be adapted to each context) into the context model.

6Again, use of the feature model in the context analysis phase requires iterative or parallel development of the context and domain models.

6. Evaluate the commonality of the applications, feasibility of constructing domain products, and potential uses and benefits of the domain products.

7. Estimate the resources for the subsequent activities considering availability of domain experts, previous work, and maturity of the domain.

8. Document the context model; define the terms used in the model in the domain terminology dictionary.

9. Validate the model against at least one application that is not included in the analysis. Also, have the model reviewed by domain experts. Record the vali-dation results in the context model documentation.

Within the scope defined from the context analysis, the problems pertaining to the domain are analyzed and modelled in the domain modelling phase. Chapter 5 describes domain modelling activities.

34 CMU/SEI-90-TR-21