|
Complete
We recommend
Domain Engineering and Domain Analysis as prerequisite reading for this technology description.
Organization domain modeling (ODM)
was developed to provide a formal,
manageable, and repeatable approach to domain engineering. The ODM method
evolved and was subsequently formalized by Mark Simos (Organon Motives, Inc.)
with collaboration and sponsorship from Hewlett-Packard Company,
Lockheed-Martin,1 and the DARPA
STARS2 program
[Simos 96]. ODM affects the
maintainability,
understandability, and
reusability characteristics of a system or family of systems.
ODM was developed and refined as part of the overall reuse/product line
approaches developed under the STARS program. The STARS reuse approach
decomposes reuse technologies into several levels or layers of abstraction,
specifically: Concepts, Processes, Methods, and Tools. An example of a
"concept" is the Conceptual Framework for Reuse Processes (CFRP), a conceptual
foundation and framework for understanding domain-specific reuse in terms of
the processes involved
[STARS 93]. An example of a "process" is the Reuse-Oriented Software Evolution (ROSE) process model, which is based on the CFRP life-cycle process model; it partitions software development into domain engineering, asset management, and application engineering; and emphasizes the role of reuse in software evolution. ODM is an example of a "method" compatible with the CFRP framework.
The primary goal of ODM is the systematic transformation of artifacts (e.g., requirements, design, code, tests, and processes) from multiple legacy systems into assets that can be used in multiple systems. The method can also be applied to requirements for new systems; the key element is to ground domain models empirically by explicit consideration of multiple exemplars, which determine the requisite range of variability that the models must encompass. ODM stresses the use of legacy artifacts and knowledge as a source of domain knowledge and potential resources for reengineering/reuse. However, one of its objectives is to avoid embedding hidden constraints that may exist in legacy systems into the domain models and assets.
Domain Engineering and Domain Analysis identifies three areas where domain analysis methods can be differentiated. Distinguishing features for ODM are:
Primary product of the analysis. The result of ODM is a
knowledge representation framework populated with a domain architecture and a
flexible asset base. It can be thought of as a reuse library designed to
support
systematic reuse
in a prescribed context; however, the method supports the use of diverse implementation techniques such as generators in the asset base.
Focus of analysis
- ODM is structured in terms of a core domain engineering life cycle, which is distinct from and orthogonal to the system engineering life cycle. The ODM life cycle is divided into three phases:
- plan domain: selecting, scoping, and defining target domains
- model domain: modeling the range of variability that can exist within the scope of the domain
- engineer asset base: engineering an asset base that satisfies some subset
of the domain variability, based on the needs of specific target customers
[Simos 96]
- Iterative scoping. The approach to systematic scoping involves structuring the ODM life cycle as a series of incremental scoping steps; each step builds upon and validates the previous step.
- Stakeholder focus. The ODM life cycle provides an up-front analysis of the organizational stakeholders and objectives. The stakeholder focus is carried throughout the life cycle with tasks to reconsider the strategic interests of stakeholders at critical points.
- Exemplar-based modeling. ODM works from a set of explicit examples, called exemplars, of the domain rather than a single, generalized example or speculation about a "general" solution.
- Emphasis on descriptive modeling. ODM places heavy emphasis on studying a set of example systems for the domain in order to derive the shape of the domain space.
- Explicit modeling of variability. ODM encourages modelers to maximize variability in the descriptive phase of modeling. This is to generate as much insight as possible about the potential range of variability in the domain.
- Methods for context recovery. ODM emphasizes identifying contextual information (e.g., language, values, assumptions, dependencies, history) embedded within an artifact to make them more dependable and predictable. (Note: This activity does not remove dependencies. This occurs during the engineering asset base phase.)
- Prescriptive asset base engineering. After descriptive modeling takes place, the prescriptive modeling phase begins. Initially, the range of functionality to be supported by the reusable assets are re-scoped and commitments are made to a real set of customers. Prescriptive features are mapped onto the structure of the asset base and to sets of specifications for particular assets. Traceability from the features back to exemplar artifacts are maintained to enable the retrieval of additional information (e.g., existing prototypes, history).
Representation Techniques. Although ODM encompasses all of
domain engineering, the core method focuses on activities that are unique to
domain engineering. Other activities that fall within, but are not specific to
domain engineering are supported through "supporting methods." This means that
ODM can be integrated with a variety of existing methods (e.g., system and
taxonomic modeling techniques) to support unique constraints or preferences of
an organization or domain. Examples of supporting methods are the methods
associated with the Reuse Library Framework (RLF)
[STARS
96c], Canvas
[STARS
96a], Domain Architecture-Based Generation for Ada Reuse (DAGAR)
[Klinger
96,
STARS 96b], and the Knowledge Acquisition for Preservation of Tradeoffs and
Underlying Rationales (KAPTUR) Tool, which is described as a part of Argument-Based Design Rationale Capture Methods for Requirements Tracing.
ODM was developed primarily to support domain engineering projects for domains that are mature, reasonably stable, and economically viable. Although all of the criteria do not need to be met, ODM is most successful when all are present. ODM can be applied in reuse programs that are in their infancy or very mature. ODM does not assume application within an established reuse program, and in fact includes some risk-reduction steps (such as up-front stakeholder analysis) that enable the use of domain analysis as a first step in establishing such a program.
However, it is recommended that the first application of ODM be on a pilot project in a relatively small domain. ODM supports evolution to larger domains or a broader reuse program.
ODM has been applied on small-scale and relatively large-scale projects. The following are examples:
- Hewlett-Packard developed a domain engineering workbook by tailoring
aspects of an early version of the ODM process model to their organizational
objectives. The workbook is being used on numerous internal domain engineering
projects within their divisions
[Cornwell
96,
Simos 96
].
The Air Force CARDS Program applied ODM in several different areas: as a means of structuring a comparative study on architecture representation languages; on the automated message handling system (AMHS) domain analysis effort; and for product-line analysis as part of the Hanscom AFB Domain Scoping effort.
ODM formed the basis for the domain engineering approach of the Army STARS
Demonstration Project. ODM processes were integrated closely with the CFRP
[STARS
93] as a higher level planning guide, and with RLF as a domain modeling
representation technology
[Lettes 96].
Before incorporating ODM into the overall reuse plan, an organization should consider the following:
- The core ODM method does not directly address the ongoing management of
domain models and assets, or the use of the assets by application development
projects. These activities are part of a larger reuse program described in
the CFRP
[STARS 93].
- ODM does not encompass the overall reuse program planning including the establishment of producer-consumer relationships between domain engineering projects and other efforts, such as system reengineering projects or planned new projects.
- ODM may not be applicable within organizations that are not prepared to commit to, or at least experiment with, systematic reuse (i.e., reuse of assets that were developed using a software engineering process that is specifically structured for reuse).
- ODM requires that an organization adopt the level of modeling rigor, the modeling styles, or approaches recommended within ODM.
- The use of ODM necessitates a technology infrastructure and level of
technical expertise sufficient to support ODM modeling needs
[Simos 96].
A complimentary technology is generation techniques.
This technology is classified under the following categories. Select a
category for a list of related topics.
|
[Cornwell 96]
|
Cornwell, Patricia Collins. "HP Domain Analysis: Producing Useful Models for
Reusable Software." HP Journal (August 1996): 46-55.
|
|
[Klinger 96]
|
Klinger, Carol & Solderitsch, James. DAGAR: A Process for Domain
Architecture Definition and Asset Implementation [online]. Available WWW
<URL:
http://source.asset.com/stars/darpa/Papers/ArchPapers.html> (1996).
|
|
[Lettes 96]
|
Lettes, Judith A. & Wilson, John. Army STARS Demonstration Project
Experience Report (STARS-VC-A011/003/02). Manassas, VA: Loral Defense
Systems-East, 1996.
|
|
[Simos 94]
|
Simos, M. "Juggling in Free Fall: Uncertainty Management Aspects of Domain
Analysis Methods," 512-521. Fifth International Conference on Information
Processing and Management of Uncertainty in Knowledge-Based
Systems. Paris, France, July 4-8, 1994. Berlin, Germany: Springer-Verlag,
1995.
|
|
[Simos 96]
|
Simos, M., et al. Software Technology for Adaptable Reliable Systems
(STARS) Organization Domain Modeling (ODM) Guidebook Version 2.0
(STARS-VC-A025/001/00). Manassas, VA: Lockheed Martin Tactical Defense
Systems, 1996.
|
|
[STARS 93]
|
Conceptual Framework for Reuse Processes Volume I, Definition,
Version 3.0 (STARS-VC-A018/001/00). Reston, VA: Software Technology for
Adaptable Reliable Systems, 1993.
|
|
[STARS 96a]
|
Canvas Knowledge Acquisition Guide Book Version 1.0
(STARS-PA29-AC01/001/00) Reston, VA: Software Technology for Adaptable,
Reliable Systems, 1996.
|
|
[STARS 96b]
|
Domain Architecture-Based Generation for Ada Reuse (DAGAR) Guidebook
Version 1.0. Manassas, VA: Lockheed Martin Tactical Defense Systems, 1996.
|
|
[STARS 96c]
|
Open RLF (STARS-PA31-AE08/001/00). Manassas, VA: Lockheed Martin
Tactical Defense Systems, 1996.
|
Liz Kean, Air Force Rome Laboratory
Dick Creps, Lockheed Martin, Manassas, VA
Teri Payton, Lockheed Martin, Manassas, VA
Mark Simos, Organon Motives, Inc., Belmont, MA
10 Jan 97 (original)
1
formerly Unisys Defense Systems, Reston, VA
2
Defense Advanced Research Projects Agency (DARPA) Software Technology for
Adaptable, Reliable Systems (STARS)
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/odm_body.html
Last Modified: 11 January 2007
|
