UML Profile for DODAF/MODAF

C4I TF

Boston

June, 2005

2

Problem Statement

• DODAF v1.0 Volume II provides guidance on using UML– Used extensively to represent DODAF architecture products

across industry– Not sufficiently precise resulting in multiple interpretations (no

one-to-one mapping between UML diagrams and DODAF products)

– Based on UML 1.x which has been superseded by UML 2

DODAF UML guidance is inadequate to facilitate communications, architecture product reuse and

maintainability, and tool interoperability

3

Solution Statement

• DODAF V 1.0 exposed a need for architecture-based model-driven systems engineering

• SysML is a UML profile for model-driven systems engineering• Initial analysis indicates good coverage of all DODAF/MODAF

views with SysML*

• Utilize UML’s systems engineering extensions wherever SysML profile is applicable

Develop a UML Profile for DODAF/MODAF that provides an industry standard UML representation of DODAF/MODAF

architecture views

* see Bailey et al in references section

4

UML Profile for DODAF/MODAF RFPScope

• Use DODAF v1.0 as a baseline• Incorporate MODAF’s additional views (Acquisition and

Strategic Capability)• Support for modeling system-of-systems architectures

– Systems that include hardware, software, data, personnel, procedures, and facilities (DOTMLPF & MOD Lines of Development )

– Service oriented architectures

[Editor’s Note: The specific requirements for DODAF v2.0 will be incorporated as they become available]

5

RFP Draft Feedback

• MODAF’s Strategic Capability Views may:– Expand scope beyond what might be sensible in one RFP, – Overlap with the Business Motivation Metamodel work in BEIDTF, – Be beyond what UML was ever intended or suitable for.

• RFP is US-UK focused. Support of the NATO AF should be added to the mandatory requirements.

• Concerns about timetable: MODAF to be published in July, RFP to be approved by Nov. DODAF v2.0 requirements are not being folded in until they become available.

• Support for service-oriented views: added as an optional requirement

• Relationship between this meta-model and CADM: Domain metamodel is a higher level of abstraction than the CADM which is a physical data model

• UML profile should not force a specific development methodology (i.e., structured vs. OO)

6

UML Profile for DODAF/MODAF RFPRequirements Summary

• Develop RFP that specifies the requirements for a UML Profile for DODAF/MODAF – Meta-model extension (abstract syntax and constraints) – Notation (concrete syntax) – Views and Viewpoints– Architecture products– Element taxonomy– Data interchange mechanism

• Optional requirements to support:– Extensibility to other architecture frameworks – Representation of architectural patterns and types such as

service oriented architectures– diagram interchange mechanism (leverage other OMG TF)

7

UML Profile for DODAF/MODAF Roadmap

April 2006Sept 2005

SysML/AP233 Alignment

Feb 2005

DODAFV 1.0(2004)

SysMLV 1.0

Adopted

OMG Kickoff(Feb 05)

RFP(Sept 05)

UML Profile for

DODAF/MODAF

SysMLV 0.9

MODAFV 1.0

(Sept 05)

Nov 2006

1st Submission

Feb 2006

8

Long Term Solution

• Develop standard for the specification of general architecture frameworks– Leverage IEEE 1471– Make applicable to a broad range of architecture frameworks

• Military and commercial e.g., Zachman Framework

– Utilize experience from UML Profile for DODAF/MODAF standardization to reduce risks

– Issue RFI followed by RFP through OMG’s ADTF