General Navigation Buttons - Home | Search | Contact Us | Site Map | Whats New
products graphic
white space
products
Software Technology Roadmap
What's New
Background & Overview
Technology Descriptions
Defining Software Technology
Technology Categories
Template for Technology Descriptions
Taxonomies
Glossary & Indexes
Feedback & Participation
Software Engineering Information Repository (SEIR)
white space
About SEI|Mgt|Eng|Acq|Collaboration|Prod.& Services|Pubs
pixel
Rollover Popup Hints for Topic Navigation Buttons above
pixel
Feature-Oriented Domain Analysis


Status

Advanced

Note

Domain Engineering and Domain Analysis provides overview information about domain analysis.

Purpose and Origin

Feature-oriented domain analysis (FODA) is a domain analysis method based upon identifying the prominent or distinctive features of a class of systems. FODA resulted from an in-depth study of other domain analysis approaches [Kang 90]. FODA affects the maintainability, understandability, and reusability characteristics of a system or family of systems.

Technical Detail

The FODA methodology was founded on two modeling concepts: abstraction and refinement. Abstraction is used to create domain products from the specific applications in the domain. These generic domain products abstract the functionality and designs of the applications in a domain. The generic nature of the domain products is created by abstracting away "factors" that make one application different from other related applications. The FODA method advocates that applications in the domain should be abstracted to the level where no differences exist between the applications. Specific applications in the domain are developed as refinements of the domain products.

Domain Engineering and Domain Analysis identifies three areas to differentiate between domain analysis methods. Distinguishing features for FODA include the following:

Primary Product of the Analysis. The primary product of FODA is a structured framework of related models that catalog the domain analysis results.

Focus of Analysis. The FODA process is divided into three phases:

  • Context analysis. The purpose of context analysis is to define the scope of a domain. Relationships between the domain and external elements (e.g., different operating environments, different data requirements, etc.) are analyzed, and the variabilities are evaluated. The results are documented in a context model (e.g., block diagram, structure diagram, dataflow diagram, etc.).
  • Domain modeling. Once the domain is scoped, the domain modeling phase provides steps to analyze the commonalities and differences addressed by the applications in the domain and produces several domain models. The domain modeling phase consists of three major activities:
    • Feature analysis. During feature analysis, a customer's or end user's understanding of the general capabilities or features of the class of systems is captured. The features, which describe the context of domain applications, the needed operations and their attributes, and representation variations are important results because the features model generalizes and parameterizes the other models produced in FODA. Examples of features include: function descriptions, descriptions of the mission and usage patterns, performance requirements, accuracy, time synchronization, etc. Features may be defined as alternative, optional, or mandatory. Mandatory features represent baseline features and their relationships. The alternative and optional features represent the specialization of more general features (i.e., they represent what changes are likely to occur in different circumstances). For optimal benefit, the resulting features model should be captured in a tool with access to rule-based language(s) so dependencies among features can be maintained and understood.
    • Information analysis. During information analysis, the domain knowledge and data requirements for implementing applications in the domain are defined and analyzed. Domain knowledge includes relevant scientific theory and engineering practice, capabilities and uses of existing systems, past system development and maintenance experience and work products, design rationales, history of design changes, etc. The purpose of information analysis is to represent the domain knowledge in terms of domain entities and their relationships, and to make them available for the derivation of objects and data definitions during operational analysis and architecture modeling. The information model may be of the form of an entity relationship (ER) model, a semantic network, or an object-oriented (OO) model.
    • Operational analysis. During operational analysis, the behavioral characteristics (e.g., dataflow and control-flow commonalities and differences, finite state machine model) of the applications in a domain are identified. This activity abstracts and then structures the common functions found in the domain and the sequencing of those actions into an operational model. Common features and information model entities form the basis for the abstract functional model. Unique features and information model entities complete the functional model. The control and data flow of an individual application can be instantiated or derived from the operational model with appropriate adaptation.
  • Architecture Modeling. This phase provides a software solution for applications in the domain. An architectural model, which is a high-level design for applications in a domain, is developed. It focuses on identifying concurrent processes and domain-oriented common modules. It defines the process for allocating the features, functions, and data objects defined in the domain models to the processes and modules.
Representation Techniques. The use of COTS methods or tools must be integrated on a case-by-case basis. Currently FODA has been integrated with tools that support object-oriented models, entity relationship models, and semantic networks.

Usage Considerations

Based upon early pilot projects applying the FODA method [Kang 90, Cohen 92], the following lessons learned should be considered:

  • A clear definition of the users of the domain model is essential. They should be well-defined during the context analysis phase.
  • Early identification of the domain experts and sources of information is important. Effectively working with domain experts is the best means to achieving adoption of the domain model by potential users.
  • The need for automated support for the domain modeling phase was identified. No modeling tools that support the FODA approach to ER modeling (i.e., ER + semantic data modeling) exist. Integration with existing modeling capabilities is achieved on a case-by-case basis. FODA was integrated with Hamilton Technologies 001 tool suite [Krut 93]. The integration was not automatic and there were areas where the 001 capabilities did not meet the FODA requirements. These were resolved through workarounds and negotiations with Hamilton Technologies.

Maturity

The FODA method is well-defined and has been applied on both commercial and military applications. It was applied to the

  • Army Movement Control Domain [Cohen 92]
  • In-Transit Visibility Modernization (ITVMOD) domain analysis effort [Petro 95, Devasirvatham 94]
  • Telecommunication Automated Prompt and Response Domain at NORTEL (Northern Telecom) [Schnell 96]
Training is available.

Costs and Limitations

For small projects, use of the simulation capabilities of a commercial tool like Statemate was effective during operational analysis in demonstrating the capabilities of a system; however, for large projects potential users must be convinced that the model and tool can be effectively used to specify a new system of the scale needed. The ability to use a modeling tool that can both capture the domain model and produce prototype code to simulate a system based upon feature selection would benefit the FODA method.

Index Categories

This technology is classified under the following categories. Select a category for a list of related topics.

Name of technology

 Feature-Oriented Domain Analysis

Application category

 Domain Engineering (AP.1.2.4)

Quality measures category

 Reusability (QM.4.4)
Maintainability (QM.3.1)
Understandability (QM.3.2)

Computing reviews category

 Software Engineering Tools and Techniques (D.2.2)

References and Information Sources

[Cohen 92] Cohen, Sholom G., et al. Application of Feature-Oriented Domain Analysis to the Army Movement Control Domain (CMU/SEI-91-TR-28, ADA 256590). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1992.
[Devasirvatham 94] Devasirvatham, Josiah, et al. In-Transit Visibility Modernization Domain Scoping Report Comprehensive Approach to Reusable Defense Software (STARS-VC-H0002/001/00). Fairmont, WV: Comprehensive Approach to Reusable Defense Software, 1994.
[Kang 90] Kang, K., et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study (CMU/SEI-90-TR-21, ADA 235785). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1990.
[Krut 93] Krut, Robert W. Jr. Integrating 001 Tool Support into the Feature-Oriented Domain Analysis Methodology (CMU/SEI-93-TR-11, ESC-TR-93-188) Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1993.
[Krut 96] Krut, R. & Zalman, N. Domain Analysis Workshop Report for the Automated Prompt & Response System Domain (CMU/SEI-96-SR-001). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1996.
[Peterson 91] Peterson, A. Spencer & Cohen, Sholom G. A Context Analysis of Movement Control Domain for the Army Tactical Command and Control System (CMU/SEI-91-SR-03). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1991.
[Petro 95] Petro, James J.; Peterson, Alfred S.; & Ruby, William F. In-Transit Visibility Modernization Domain Modeling Report Comprehensive Approach to Reusable Defense Software (STARS-VC-H002a/001/00). Fairmont, WV: Comprehensive Approach to Reusable Defense Software, 1995.
[Schnell 96] Schnell, K.; Zalman, N.; & Bhatt, Atul. Transitioning Domain Analysis: An Industry Experience (CMU/SEI-96-TR-009). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1996.

Current Author/Maintainer

Liz Kean, Air Force Rome Laboratory

External Reviewers

Spencer Peterson, SEI

Modifications

10 Jan 97 (original)
The Software Engineering Institute (SEI) is a federally funded research and development center sponsored by the U.S. Department of Defense and operated by Carnegie Mellon University.

Copyright 2007 by Carnegie Mellon University
Terms of Use
URL: http://www.sei.cmu.edu/str/descriptions/foda_body.html
Last Modified: 11 January 2007