Background - The Systems Engineering DSIG

Download Report

Transcript Background - The Systems Engineering DSIG

UML Profile for DODAF/MODAF
C4I TF
Boston
June, 2005
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
2
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*
Develop a UML Profile for DODAF/MODAF that provides an
industry standard UML representation of DODAF/MODAF
architecture views
• Utilize UML’s systems engineering extensions wherever
SysML profile is applicable
* see Bailey et al in references section
3
UML Profile for DODAF/MODAF RFP
Scope
• 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]
4
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)
5
UML Profile for DODAF/MODAF RFP
Requirements 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)
6
UML Profile for DODAF/MODAF
Roadmap
DODAF
V 1.0
(2004)
MODAF
V 1.0
(Sept 05)
OMG
Kickoff
(Feb 05)
1st
RFP
(Sept 05)
Submission
UML Profile
for
DODAF/MODAF
SysML
V 1.0
Adopted
SysML
V 0.9
SysML/AP233 Alignment
Feb 2005
Sept 2005
Feb 2006
April 2006
Nov 2006
7
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
8