UML Profile for DODAF/MODAF

1. 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 DODAFV 1.0 (2004) MODAFV 1.0 (Sept 05) UML Profile for DODAF/MODAF OMG Kickoff (Feb 05) 1st Submission RFP (Sept 05) SysMLV 0.9 SysMLV 1.0 Adopted SysML/AP233 Alignment Feb 2005 Feb 2006 April 2006 Nov 2006 Sept 2005

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