Object Management Group
First Needham Place
250 First Avenue, Suite 100
Needham, MA 02494
UML Profile for DODAF/MODAF (UPDM)
Request For Proposal
OMG Document: syseng/05-05-01 (To Be Assigned)
Letters of Intent due: <month> <day>, <year>
Submissions due: <month> <day>, <year>
Objective of this RFP
This RFP solicits proposals for the following:
• UML Profile for the Department of Defense Architecture Framework
(DODAF) and the UK’s Ministry of Defence Architecture Framework
For further details see Chapter 6 of this document.
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 1
6 SPECIFIC REQUIREMENTS ON PROPOSALS
This section lists the specific requirements for a UML Profile for DODAF/MODAF
(UPDM) that provides an industry standard UML representation for DODAF v1.0
architecture products and supports evolution to DODAF v2.0. Utilizing a common
modeling language with a standard architecture framework will significantly enhance
the quality, productivity, and effectiveness associated with architecture and system of
systems modeling, including improved communications, model/data reuse, and tool
interoperability; and will reduce re-training requirements for different tools and
6.1 PROBLEM STATEMENT
The current DODAF v1.0 Volume II includes guidance for representing DODAF
architecture products using UML. However, this guidance is not sufficiently precise
or complete. The current guidance has been interpreted many different ways by
architects and users of this framework and by vendors who are implementing
DODAF in their UML tools. As a result, the DODAF UML representations do not
fully serve their intended use to support communications among stakeholders and re-
use of the architecture products and data. The different vendor implementations also
result in interoperability issues between tools, and additional training requirements
for the users. In addition, UML v1.x has been superseded by UML v2.0 that is
currently being augmented with a Systems Modeling Language (SysML) profile for
Systems Engineering. The latter provides a much more robust system of systems
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 2
Work is currently underway to evolve DODAF v1.0 to DODAF v2.0. This may add
new requirements for the UPDM. DODAF v2.0 will define several overlays that
support key transformational processes (e.g., acquisition, budgeting and portfolio
management) and must maintain architectural consistency across the overlays.
[Editor’s Note: elaborate on DODAF v2.0 requirements as they become available].
MODAF is the UK equivalent of DoDAF tailored to meet the needs of the UK
Defence community. The UK MOD have built upon the DoDAF views and
introduced two new Viewpoints covering Strategic Capability (High-level User
requirements and Enterprise capability trade-offs) and Acquisition (Programmatic)
issues. These new developments are likely to be used by the International community
in the future, when data is exchanged, and so need to be considered in the
development of the profile.
6.2 SCOPE OF PROPOSALS SOUGHT
The scope of this RFP is for a UPDM that satisfies the requirements outlined below.
This includes representations for DODAF/MODAF views and products for modeling
of the systems architecture (Systems View) along with their associated standards
(Technical View) within the context of the business or enterprise architecture
(Operational View). In addition it should be able to represent the UK modeling of the
capability and strategic intent of the Enterprise (Strategic View) and the
programmatic associated with the procurement of defense systems (Acquisition
View). It should also provide a sufficiently robust capability and enhancements
needed to support newly defined requirements for DODAF v2.0.
Section 6.5 includes the following categories of requirements for the UPDM:
• Meta-model (abstract syntax and constraints)
• Standard Notation (concrete syntax)
• Views and Viewpoints
• Architecture products
• Extensible library of reusable architecture elements and patterns
• Standard data interchange mechanism (e.g., XMI)
Submitters may provide partial responses to these requirements, along with a
roadmap to address the complete requirements. The evaluations will assess the level
of completeness as part of the evaluation criteria. It is expected that follow-on RFP’s
may include additional and refined requirements as the user and vendor communities
learn from their experiences in applying the profile.
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 3
The intent is to use the UPDM to directly model architectures for a broad range of
complex systems, which can include hardware, software, data, personnel, and facility
elements. Such an architecture model must support the analysis, specification,
design, and verification of complex systems, and is intended to improve the ability to
exchange architecture information amongst tools, and to help ensure consistent
modeling from the system of systems level down to lower levels of design and
implementation. The profile should provide the modeling of operational activities,
nodes, systems, hardware, software, and organizational components, interfaces,
system functions and services, performance, and physical characteristics. In addition,
the profile should allow for the modeling of operational views that span the full
spectrum of Doctrine, Organization, Training, Materiel, Leadership & education,
Personnel, and Facilities (DOTMLPF and the UK MOD equivalent Lines of
Development). The additional MODAF views (and possibly DODAF v2.0) will also
introduce a requirement to model capabilities, services, projects, system ports,
protocols, physical properties and units of measure. Any profile should take into
account aspects of the physical world that UML has not previously addressed. These
include usages of systems (i.e. a type of system being used in an assembly structure)
and instances of systems, nodes, etc. A great deal could be learned from the SysML
experience in this area, as well as from ISO10303 STEP.
An extension of UML in response to the UML for Systems Engineering RFP is
currently being developed based on UML v2.0 to support the specification, design,
and analysis of complex systems. This extension is called the Systems Modeling
Language (SysML), and is expected to begin adoption by the OMG in 2005. SysML
should provide a foundation for the UPDM to support modeling of system of
systems. (Editor’s Note: We expect SysML to be used for this RFP even though it is
in draft version at the time of this RFP publication. We expect SysML to be formally
adopted before submissions to this RFP are due.)
If additional extensions are needed, the UPDM must rely on extension mechanisms
provided by UML and MOF. A profile selects and constrains the use of existing
UML modeling elements, optionally with new terminology and notations specific to
that profile. Other extension mechanisms provided by the UML and MOF
specifications may also be used, such as defining new types of UML modeling
elements and model libraries. A combination of these extension mechanisms may be
used as well. For further information about the mechanisms that UML provides for
its own extension, see the specifications referenced in Section 6.3 below.
6.3 RELATIONSHIP TO EXISTING OMG SPECIFICATIONS
Proposals may reference and build upon any of the OMG specifications identified in
this section. In each case, the most recent version is applicable, unless the most recent
version was adopted less than six months before the final submission to this
specification, in which case the previous version may be used. Proposals should
identify the specific dependencies they have on any of these specifications including
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 4
their specific version. Document numbers that appear below are all available as
public documents from the OMG web site. The submitters are encouraged to
leverage other work in progress as well.
Specification category Topical area / domain Current Adopted Document #
Meta-Object Facility (MOF™) modeling 1.4 formal/2002-04-03
2.0 finalization ptc/2004-01-13
MOF 2.0 XMI modeling 1.0 finalization ptc/2004-06-11
Unified Modeling Language™ modeling 1.5 formal/2003-03-01
- Infrastructure 2.0 finalization ptc/2003-09-15
- Superstructure 2.0 finalization ptc/2004-10-02
- Diagram Interchange 2.0 finalization ptc/2003-09-01
- OCL 2.0 finalization ptc/2003-10-14
UML™ Testing Profile modeling 1.0 finalization ptc/2004-04-02
UML™ For Systems modeling 1.0 TBD
XML Metadata Interchange modeling (XML DTDs) 1.2 formal/2002-01-01
modeling (XML Schema) 2.0 formal/2003-05-02
6.4 RELATED ACTIVITIES, DOCUMENTS AND STANDARDS
The OMG Systems Engineering Domain Special Interest Group (SE DSIG) website
(http://syseng.omg.org) provides extensive background materials, including sources
used to derive the requirements included in this RFP that may be of benefit to a
submitter. Detailed, up-to-date web links for each of the related activities, documents,
and standards summarized in the sections below are provided at
6.4.1 DoDAF v2.0
DoDAF v2.0 is currently in development, and will focus on defining several overlays
to support key transformational processes (e.g., budgeting and portfolio
management). To maintain architectural consistency across the overlays, an
underlying meta-model of architecture elements and relationships is maintained.
The specific requirements for DODAF v2.0 will be incorporated as they become
MODAF is the UK Ministry of Defence Architecture Framework. It is based on
DODAF with some minor changes to TV-1, OV-1, OV-2, SV-1 and SV-2. In
addition to this, MODAF adds two new viewpoints:
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 5
Strategic Capability Views – these views define the high level capability vision and
strategic intent, the capabilities and sub-capabilities (capability functions) required to
support that vision. In addition, the dependencies between capabilities, the phasing in
and out of systems that support the capabilities (planned time periods of capability),
and the organizations in which those systems are to be deployed are also covered.
Acquisition Views – these views define the project team structures required to
deliver network enabled capabilities (cf NCW). They also define the inter-project
dependencies and specify the lines of development status (cf DOTMLPF) at
significant project milestones.
The UK has aligned the usage of an Architecture Framework to its Communities of
Interest (CoI’s) processes, e.g. how MODAF should be used by those involved in
Acquisition of Concepts & Doctrine. This approach increases the need to exchange
data between the CoI’s.
MODAF has begun to develop a UML profile – initially to support XMI-based file
exchange between MODAF tools and repositories. The profile covers the whole of
MODAF, and is therefore a superset of DODAF.
6.4.3 ISO 10303 (STEP) - AP233
ISO 10303 – AP233 (AP233), the Application Protocol for Systems Engineering, is
focused on developing a neutral data format to exchange systems engineering
information among tools. AP233 is being standardized under the ISO TC-184
(Technical Committee on Industrial Automation Systems and Integration), SC4
(Subcommittee on Industrial Data Standards), and is part of the larger STEP effort,
which provides standardized models and infrastructure for the exchange of product
model data. The UPDM development should be closely aligned with the on-going
development of AP233, especially in the area of systems, because AP233 is being
evaluated as the preferred protocol for exchanging architecture data between tools
that are based on the CADM schema and tools that are based on other meta-models,
or the MOF.
6.4.4 IEEE 1471
This recommended practice addresses the activities of the creation, analysis, and
sustainment of architectures of software-intensive systems, and the recording of such
architectures in terms of architectural descriptions. A conceptual framework for
architectural description is established. The content of an architectural description is
defined. Annexes provide the rationale for key concepts and terminology, the
relationships to other standards, and examples of usage. [IEEE 1471] Appendix 3
presents the IEEE 1471 definitions as used in this RFP.
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 6
6.4.5 Other Standards
In addition to the above standards, other architecture modeling standards are listed in
the references section of this RFP such as ISO/IEC 10746:1998, which is ISO’s
Reference Model for Open Distributed Processing; ISO 15704:2000, which is ISO’s
document on Requirements for Enterprise-Reference Architectures and
Methodologies, and ISO 15926:2003 which is a generic, conceptual data model
designed to be used in conjunction with reference data or upper ontology.
6.5 MANDATORY REQUIREMENTS
6.5.1 RFP Requirements Traceability Matrix
The “Resolution of RFP requirements and requests” section of any response to this
RFP shall include a matrix (see Table 1) indicating how the proposed solution
satisfies each requirement in Sections 6.5 and 6.6, supplying the following
information about each requirement:
a. RFP requirement
b. Whether the proposed solution is a full or partial satisfaction of the
requirement, or whether there is no solution provided
c. Summary description of how the profile addresses the requirement
d. Specific metaclasses that address the requirement
e. Reference to specification sections that address specify the abstract and
concrete syntax that satisfies the requirement
f. Applicable references to DODAF and other source documentation
Table 1. Requirements Traceability Matrix
Req't Requirement Compliance Requirement Metaclass Spec Applicable
id Descriptor (Y/N, Partial) Satisfaction Extension Reference DODAF Ref
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 7
6.5.2 Sample Problem:
A sample architecture model (including an XMI 2.1 representation of the sample
model) must also be provided that demonstrates how your submission satisfies the
requirements and addresses the issues listed in section 6.7.
6.5.3 List of Mandatory Requirements
Notes in the mandatory requirements section have been included to provide
additional explanatory information, and are not intended to present mandatory
220.127.116.11 Meta-model. UPDM shall provide a meta-model that includes:
a) Terms and definitions
b) Concepts defined as abstract syntax that extend the UML meta-model or an
c) Constraints on elements in the abstract syntax that ensures connectivity and
integrity of model
18.104.22.168 Notation. UPDM shall provide a standard notation (concrete syntax) that
maps to the meta-model (requirement 22.214.171.124 above) using UML extension
126.96.36.199 Views and Viewpoints. UPDM shall provide the capability to represent
views and viewpoints:
a. DoDAF and MODAF-specific views and viewpoints.
b. A generic mechanism for defining additional views and viewpoints for
different stakeholders and overlays.
188.8.131.52 Architecture products. UPDM shall provide the capability to represent
architecture products in one or more diagrams and tables using the standard notation
(requirement 184.108.40.206 above).
220.127.116.11 Extensible library. UPDM shall provide the capability to represent an
extensible library of reusable architecture elements (e.g., UJTLs) and patterns (e.g.,
C2 organizational construct, document types).
6.6 OPTIONAL REQUIREMENTS
6.6.1 Element Taxonomy. An architecture elements taxonomy may be used to
specialize the generic Architecture Framework concepts with commonly used
terminology, equipment types, etc. The taxonomy provides specific definitions for
the (generic) elements defined in the framework – i.e. it provides reference data.
Efforts are underway amongst the US, UK, Canadian and Australian defense
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 8
departments to develop a top-level taxonomy that can be agreed at an international
6.6.2 Extensibility to Other Architecture Frameworks. UPDM may provide a
capability to support other military architecture frameworks (e.g., NATO’s AF,
France’s Atelier de Gestion de l’ArchiTecturE des SIC (AGATE) AF, Australian
Defence Organisation’s AF).
6.6.3 Standard diagram interchange mechanism. UPDM may provide a
mechanism for exchange of diagram layout (i.e., Diagram Interchange).
6.7 ISSUES TO BE DISCUSSED
The issues below will be considered during submission evaluation. The discussion
should not be part of the proposed normative specification but can be included in a
non-normative appendix. Proposals shall discuss and/or demonstrate via sample
problem how the submission addresses the following concerns:
traceability of architecture models to requirements
various types of architectures (e.g., services oriented architectures and net-centricity,
6.8 EVALUATION CRITERIA
6.8.1 Clarity of the proposed specification for the purpose of implementing conforming
modeling tools; ease of reviewing for correctness.
6.8.2 The precision, completeness, compactness, and clarity of the abstract and
6.8.3 Level of training required for understanding and use of the language
6.9 OTHER INFORMATION UNIQUE TO THIS RFP
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 9
6.10 RFP TIMETABLE
The timetable for this RFP is given below. Note that the TF or its parent TC may, in
certain circumstances, extend deadlines while the RFP is running, or may elect to
have more than one Revised Submission step. The latest timetable can always be
found at the OMG Work In Progress page at http://www.omg.org/schedules/ under
the item identified by the name of this RFP. Note that “<month>” and “<approximate
month>” is the name of the month spelled out; e.g., January.
Event or Activity Actual Date
Preparation of RFP by TF
RFP placed on OMG document server Sept. meeting three week rule
(August 22, 2005)
Approval of RFP by Architecture Board
Review by TC
TC votes to issue RFP <approximate month>
LOI to submit to RFP due <month> <day>, <year>
Initial Submissions due and placed on OMG <month> <day>, <year>
document server (“Three week rule”)
Voter registration closes <month> <day>, <year>
Initial Submission presentations <month> <day>, <year>
Preliminary evaluation by TF
Revised Submissions due and placed on OMG <month> <day>, <year>
document server (“Three week rule”)
Revised Submission presentations <month> <day>, <year>
Final evaluation and selection by TF
Recommendation to AB and TC
Approval by Architecture Board
Review by TC
TC votes to recommend specification <approximate month>
BoD votes to adopt specification <approximate month>
Appendix AReferences and Glossary Specific to this RFP
A.1 REFERENCES SPECIFIC TO THIS RFP
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 10
Friedenthal, S., Kobryn, C. "Extending UML to Support a Systems Modeling
Language," Proceedings of the INCOSE 2004 International Symposium, June, 2004
[IDEAS] – the IDEAS Group – www.ideasgroup.org
“Recommended Practice for Architectural Description of Software-Intensive
Systems,” IEEE, 2000
[IEEE Std 1471 and Beyond]
International Council on Systems Engineering
Information Technology – “Open Distributed Processing -- Reference Model,” ISO,
”Industrial Automation Systems And Integration -- Integration Of Life-Cycle Data
For Process Plants Including Oil And Gas Production Facilities -- Part 2: Data
model, ISO 2003
Industrial Automation Systems – “Requirements for Enterprise-Reference
Architectures and Methodologies,” ISO, 2000
MOD Architectural Framework (MODAF), To Be published-July 2005, UK
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 11
A.3 DEFINITIONS SPECIFIC TO THIS RFP
architecture framework - An architecture framework establishes terms and concepts
pertaining to the content and use of architectural descriptions. [IEEE 1471]
acquirer - An organization that procures a system, software product, or software service
from a supplier. (The acquirer could be a buyer, customer, owner, user, or
purchaser.) [IEEE 1471]
architect - The person, team, or organization responsible for systems architecture.
architecting - The activities of defining, documenting, maintaining, improving, and
certifying proper implementation of an architecture. [IEEE 1471]
architectural description (AD) - A collection of products to document an architecture.
architecture - The fundamental organization of a system embodied in its components,
their relationships to each other, and to the environment, and the principles guiding
its design and evolution. [IEEE 1471]
life cycle model - A framework containing the processes, activities, and tasks involved
in the development, operation, and maintenance of a software product, which spans
the life of the system from the definition of its requirements to the termination of its
use. [IEEE 1471]
system - A collection of components organized to accomplish a specific function or set
of functions. [IEEE 1471]
system stakeholder - An individual, team, or organization (or classes thereof) with
interests in, or concerns relative to, a system. [IEEE 1471]
view - A representation of a whole system from the perspective of a related set of
concerns. [IEEE 1471]
viewpoint - A specification of the conventions for constructing and using a view. A
pattern or template from which to develop individual views by establishing the
purposes and audience for a view and the techniques for its creation and analysis.
Appendix BGeneral Reference and Glossary
B.1 GENERAL REFERENCES
The following documents are referenced in this document:
[ATC] Air Traffic Control Specification,
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 13
[BCQ] OMG Board of Directors Business Committee Questionnaire,
[CCM] CORBA Core Components Specification,
[CORBA] Common Object Request Broker Architecture (CORBA/IIOP),
[CSIV2] [CORBA] Chapter 26
[CWM] Common Warehouse Metamodel Specification,
[DAIS] Data Acquisition from Industrial Systems,
[EDOC] UML Profile for EDOC Specification,
[EJB] “Enterprise JavaBeans™”, http://java.sun.com/products/ejb/docs.html
[FORMS] “ISO PAS Compatible Submission Template”. http://www.omg.org/cgi-
[GE] Gene Expression,
[GLS] General Ledger Specification ,
[Guide] The OMG Hitchhiker's Guide,, http://www.omg.org/cgi-bin/doc?hh
[IDL] ISO/IEC 14750 also see [CORBA] Chapter 3.
[IDLC++] IDL to C++ Language Mapping, http://www.omg.org/technology/documents/
[MDAa] OMG Architecture Board, "Model Driven Architecture - A Technical
[MDAb] “Developing in OMG's Model Driven Architecture (MDA),”
[MDAc] “MDA Guide” (http://www.omg.org/docs/omg/03-06-01.pdf)
[MDAd] “MDA "The Architecture of Choice for a Changing World™"”,
[MOF] Meta Object Facility Specification,
[MQS] “MQSeries Primer”, http://www.redbooks.ibm.com/redpapers/pdfs/redp0021.pdf
[NS] Naming Service,
[OMA] “Object Management Architecture™”, http://www.omg.org/oma/
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 14
[OTS] Transaction Service,
[P&P] Policies and Procedures of the OMG Technical Process, http://www.omg.org/cgi-
[PIDS] Personal Identification Service,
[RAD] Resource Access Decision Facility,
[RFC2119] IETF Best Practices: Key words for use in RFCs to Indicate Requirement
[RM-ODP] ISO/IEC 10746
[SEC] CORBA Security Service,
[TOS] Trading Object Service,
[UML] Unified Modeling Language Specification,
[UMLC] UML Profile for CORBA, http://www.omg.org/technology/documents/formal/
[XMI] XML Metadata Interchange Specification,
[XML/Value] XML Value Type Specification,
B.2 GENERAL GLOSSARY
Architecture Board (AB) - The OMG plenary that is responsible for ensuring the
technical merit and MDA-compliance of RFPs and their submissions.
Board of Directors (BoD) - The OMG body that is responsible for adopting
Common Object Request Broker Architecture (CORBA) - An OMG distributed
computing platform specification that is independent of implementation languages.
Common Warehouse Metamodel (CWM) - An OMG specification for data
CORBA Component Model (CCM) - An OMG specification for an implementation
language independent distributed component model.
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 15
Interface Definition Language (IDL) - An OMG and ISO standard language for
specifying interfaces and associated data structures.
Letter of Intent (LOI) - A letter submitted to the OMG BoD’s Business Committee
signed by an officer of an organization signifying its intent to respond to the RFP and
confirming the organization’s willingness to comply with OMG’s terms and
conditions, and commercial availability requirements.
Mapping - Specification of a mechanism for transforming the elements of a model
conforming to a particular metamodel into elements of another model that conforms
to another (possibly the same) metamodel.
Metadata - Data that represents models. For example, a UML model; a CORBA
object model expressed in IDL; and a relational database schema expressed using
Metamodel - A model of models.
Meta Object Facility (MOF) - An OMG standard, closely related to UML, that
enables metadata management and language definition.
Model - A formal specification of the function, structure and/or behavior of an
application or system.
Model Driven Architecture (MDA) - An approach to IT system specification that
separates the specification of functionality from the specification of the
implementation of that functionality on a specific technology platform.
Normative – Provisions that one must conform to in order to claim compliance with
the standard. (as opposed to non-normative or informative which is explanatory
material that is included in order to assist in understanding the standard and does not
contain any provisions that must be conformed to in order to claim compliance).
Normative Reference – References that contain provisions that one must conform to
in order to claim compliance with the standard that contains said normative reference.
Platform - A set of subsystems/technologies that provide a coherent set of
functionality through interfaces and specified usage patterns that any subsystem that
depends on the platform can use without concern for the details of how the
functionality provided by the platform is implemented.
Platform Independent Model (PIM) - A model of a subsystem that contains no
information specific to the platform, or the technology that is used to realize it.
Platform Specific Model (PSM) - A model of a subsystem that includes information
about the specific technology that is used in the realization of it on a specific
platform, and hence possibly contains elements that are specific to the platform.
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 16
Request for Information (RFI) - A general request to industry, academia, and any
other interested parties to submit information about a particular technology area to
one of the OMG's Technology Committee subgroups.
Request for Proposal (RFP) - A document requesting OMG members to submit
proposals to the OMG's Technology Committee. Such proposals must be received by
a certain deadline and are evaluated by the issuing task force.
Task Force (TF) - The OMG Technology Committee subgroup responsible for
issuing a RFP and evaluating submission(s).
Technology Committee (TC) - The body responsible for recommending technologies
for adoption to the BoD. There are two TCs in OMG – Platform TC (PTC), that
focuses on IT and modeling infrastructure related standards; and Domain TC (DTC),
that focus on domain specific standards.
Unified Modeling Language (UML) - An OMG standard language for specifying the
structure and behavior of systems. The standard defines an abstract syntax and a
graphical concrete syntax.
UML Profile - A standardized set of extensions and constraints that tailors UML to
XML Metadata Interchange (XMI) - An OMG standard that facilitates interchange
of models via XML documents.
UML Profile for DODAF/MODAF RFP – DRAFT May 30, " 17