Transcript UPDM - Object Management Group

UPDM – UML profile for DoDAF
and MODAF
Briefing to the DoDAF WG
May 16, 2007
UPDM – UML Profile for DoDAF and MODAF
Introduction to the UPDM specification submission
 Background
 Approach
 Highlights
 Deep dive if requested
2
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Background – The Object Management Group (OMG)
 OMG is an international industry consortium that produces industry
standards using a rigorous technology adoption process
– UML, SysML, MDA™, etc.
 UPDM Requirements derived from DoDAF and MODAF
requirements
 UPDM development included broad industry participation from tool
vendors and end users, as well as DoD/MOD inputs to requirements
 UPDM supports current DoDAF/MODAF requirements and can
evolve to meet future needs
– Can produce standard DoDAF products
– Leverages cross industry standards based approaches (e.g., MDA™ ,UML,
SysML) to enhance tool and architecture data interoperability
– MDA™ foundation enables UPDM to evolve with DoDAF v2 and beyond as
needs evolve (i.e. SOA)
– UPDM is methodology agnostic (structured, OO, ..)
3
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Background: UPDM Timeline – Teams and Submissions
DoDAF v 1.0
(2004)
DoDAF v 1.5
Draft Inputs
MODAF
v 1.0
OMG Kickoff
RFP
issued
Three Initial
Submissions
UST and Telelogic
Merge
Feb 2005
4
Sept 2005
June
2006
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
Two Revised
Submissions
Unified
Submission
OMG
Adopts
UPDM
Team 1 & Alpha
Merge
Nov Dec
2006 2006
March
2007
June
2007
UPDM – UML Profile for DoDAF and MODAF
Background – Briefings and Feedback
2007
Event
2006
Event
Jun
OMG C4I and Board
Dec
Jun
MODAF – TBD - Brussels
Mr. Brian Wilczynski Key Note speaker at
OMG’s UPDM info Day
Jun
NATO – TBD - Brussels
Dec
May
DISA - TBD
Mr. Tillotson key note speaker at OMG’s
Architecture info day (C4I, UPDM, and
Software Assurance)
May
Impact Presentation - commercial
Nov
AFITC presentation
May
Briefing to DoDAF WG
Oct
Briefing to SAF/XC on UPDM
May
Briefing to NCOIC Technical
Oct
Briefing to DODAF WG on UPDM
Sep
NCOIC Presentation
Sep
Joint NII and OSJTF briefing to
Acquisition M&S WG
Jul
Army ARCIC workshop on DODAF
support for OO/UML
Feb
Coordination meeting with MOD and DoD
Sept 05
Briefing on UPDM to OSJTF workshop
May 05
Briefing to DODAF WG
May 05
Workshop at Mitre with OSD NII, OSJTF,
and Army PEO GCS
May
JFCOM Presentation
Apr
DoD Architects Conference
Apr
INCOSE Review / Study – Patterns
Apr
Briefing to SAF/XC on UPDM
Mar
OMG C4I Presentation / Review
Jan
Briefing to INCOSE International
Workshop
Jan
Briefing to DODAF WG Vol II review
session on UPDM
5
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Background: Summary of DoDAF
NODES
TIME A
T1
T2
T3
B
XY
Z
X
Y
C
System Functionality
Description (SV-4)
Y
X
Systems Functionality
Sequence and Timing
Description (SV-10 a/b/c)
Systems Interface
Description (SV-1)
Physical Schema
SV-11
Activity to System
Function (SV-5)
System - System
Matrix (SV-3)
Systems Evolution
Description (SV-8)
Technical Architecture
Profile (TV-1)
Standards Technology
Forecast (TV-2)
CONNECTION
TO NODE B
NODE A
System 1
System 2
One-Way
Communications
Link
Two-Way
Communications
Links
System 4
System 3
CONNECTION
TO NODE B
Local Area Net
System 5
EXTERNAL
CONNECTION
(OUTSIDE THE
NODES OF INTEREST)
CONNECTION
TO NODE C
Systems Communications
Description (SV-2)
Operational
Systems Data Exchange
Matrix (SV-6)
Systems Performance
Parameters Matrix (SV-7)
Operational Concept
Description (OV-1)
Systems Technology
Forecast (SV-9)
Operational Activity
Model (OV-5)
• .....
• .....
• .....
Organizational
Relationships
Chart (OV-4)
6
Node Connectivity
Description (OV-2)
•
-
Logical Data
Model (OV-7)
Information
Exchange Matrix
(OV-3)
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
NODES
TIME A
T1
T2
T3
B
C
Operational Activity
Sequence and Timing
Description (OV-6 a/b/c)
UPDM – UML Profile for DoDAF and MODAF
Background – Summary of MODAF
Inputs:
Outputs:
Doctrine
& SAGs
Inform
Standards
Prog Plans
7
Inform
Inform
Inform
DoDAF Views
Cap Audit
Legacy
Systems
Inform
Strategic View
Operational View
Optimise
Capability
Phasing
Provides
Operational
Concepts
Technical View
Defines System
Components &
Key Interface
Points
Structures the
Mandated
Standards
Acquisition View
Provides the
Route map
System View
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
Improved Policy
Coherent Effects
System of Systems
Standards and
Principles
NEC Roadmap
Context
UPDM – UML Profile for DoDAF and MODAF
Approach – Submission Documents
UPDM
Joint Submission
Compliance
Level 1
c4i/07-02-01
Class Library (xmi)
c4i/07-03-07
Domain Meta-model (xmi)
c4i/07-02-02
c4i/07-03-04
Profile (xmi)
c4i/07-03-05
c4i/07-03-06
UPDM Class Library, Domain
Meta-model, Profile (HTML)
c4i/07-03-09
c4i/07-03-09
Errata
8
Compliance
Level 0
c4i/07-03-08
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Approach - Addressing Request for Standard Submission
Requirements
 Mandatory (Submission Annex A)
–
–
–
–
–
[6.5.1] Meta Model (abstract syntax and constraints)
[6.5.2] Profile
[6.5.3] Notation (concrete syntax)
[6.5.4] DoDAF 1.0 and MODAF 1.0 artifacts
[6.5.5] Additional Views and Viewpoints
–
–
[6.5.6] Element Taxonomy Reference
[6.5.7] Data Interchange
(Sections 4 - 6)
(Sections 4 - 6)
(Sections 4 - 6)
(Sections 4 – 6 for semantics)
(Sections 4 & 6 for custom
Views and Section 7 on
Extensibility)
(Sections 4 & 6
(Supplementary Files)
 Optional
–
–
–
–
9
[6.6.1] Domain Meta Model
Data Interchange Mappings and Transformations
Extensibility to Other Architecture Frameworks
Representation of Architectural Patterns
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
(Annex C)
(Supported by XMI)
(Section 7, SOA Extensions)
(SOA, UML)
UPDM – UML Profile for DoDAF and MODAF
Approach
 Unified submission
– Combines the perspectives of the initial submission teams
– Exploitation of both UML and SysML
– Compliant specification that addresses the needs of DoDAF and MODAF
– Supports both architect and System Engineers perspectives
 Domain Metamodel
 XMI exports
 Working proof of concept
– Demonstrated at OMG conference
 DoD relevant example included
 HTML export of all models
10
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Approach – Principles for Designing UPDM
Topic
Direction
Comment
Frameworks
DoDAF, MODAF, FEA
Acceptance
Open Standard
Direction
NCO, SOA, System Engineering
Schedule
On Schedule
Professions
Plus more
Must be widely supported Open Standard
Tools can import/export legacy
User feedback is best
Architect, Engineer, Developer, more
Professions interlock and sharing
Modeling
UML & SysML
Model interoperability and reuse
Accuracy
Proof of Concept
Rigorous software engineering method, MDA™
Specification
Model Transforms
Generate specifications from models
Governance
Agile, team based
Consensus based approach
Semantics
Interchange
Profile
Architecture
Industries
11
Domain Model drives Profile
XMI
MDA™
Model Oriented
Widely applicable
DoDAF domain model ability to reason
Import/export to repositories and tools
Transforms between standards
Models with Multiple Views, ad hoc model queries
Defense, Commercial, Academic
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Approach: Role of UPDM Domain MetaModel
 DoDAF and MODAF concepts were used as inputs for the
UPDM Domain MetaModel
 The Domain MetaModel established the context for the
UML profile
DoDAF
MODAF
Domain MetaModel
mple
exa
UML Profile
12
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Approach – Model-Based
 As the complexity of a problem increases, the use of
modeling becomes necessary to describe both the
problem space as well as the solution.
 Providing additional DoDAF/MODAF semantics to the
modeling experience allows users to create models that
exhibit those semantics.
 These semantics provide consistency and allow
generation of the typical DoDAF/MODAF products as
views of the model contents.
 The model becomes the repository from which various
views can be extracted.
13
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Approach: Profile Conformance
 The profile has two conformance levels
– Level 0 – all UML may be used
– Level 1 – defines SysML-specific extensions to Level-0
 We expect models created conformant with Level 0 and Level 1 to
be interoperable since
– Standard UPDM profile being used
– XMI 2.1 specified as the basis for interchange
– UML 2.1.1 specified as the base language for Level 0
– Limited to the UML4SysML subset
– Level 1 extensions based on standard SysML profile of UML
UML
Level 0
UML4SYSML
Level 1
SYSML
14
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Approach: The OV-1 for UPDM
UPDM Domain Meta Model
UPDM Profile Meta Model
Graphics
View Gen.
BPMN
View
Level 1
SysML
UML4SYSML
IDEF
Transform
Project Mngt
UPDM
Profile
and
Library
Other
Profiles
Spreadsheet
URI +
model
data
External Links
SOA Profile
Models
IDEF
Models
BPMN
Apply
Icons, Attributes
Level 0
15
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
Import
& Export
UML
XMI
UPDM – UML Profile for DoDAF and MODAF
Approach: Proof of Concept
 Technology Proof of Concept:
 Approach was to build and test iteratively
– Most of the time this worked
– Sometimes we were surprised
– Some corner cases of UML were not addressed in the Rational
modeling tools
– In all cases, we were able to identify the shortcomings and working
with engineering, develop workarounds and schedule product fixes
 Domain Proof of Concept:
– Engaged with team members steeped in DoDAF experience
– Applied UPDM profile and modeled real-life example
– Finding an unclassified example was difficult!
16
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Approach - Features
Feature
Comment
Capability and Effects
Unification of Strategic, Operational and Service elements
Operational to Systems Mappings
SystemsNode and OperationalActivityRealization maps to System Functions
Service Oriented Architecture
Model operational nodes, systems and actors as Services
External Systems
Links to taxonomies, requirements, repositories, view generators
Traceability
Context free activities and decomposition of Activities and System Functions
Community
Link Engineers and Architects
Reuse
Open Standard Model, import / export, transforms, queries, reporting
Validation
Open Standard Model, queries for validation
FEA Alignment
Top down modeling from Enterprise, StrategicMission, Goals and Vision
Roles Competency
Roles, competency, resources and operational nodes
Activity Contexts
Allocation of activities and system functions to operational nodes and system
Reporting
DoDAF and MODAF views and ad hoc model queries, export
Patterns
Reusable Asset Specification for pattern repository
Extensibility
Viewpoints/stakeholders External references
17
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Errata Summary
Minor changes to the specification resulting from
validation and testing.
 OCL stereotype specialization validation
 Remove “UPDM” from stereotype names
 Fix Architecture View OCL
 Several typos
 One diagram missing “ownership” line
 Other OCL bugs
 Added note on patterns and other architectures
18
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution – Node and Operational Capability
Profile specification metamodel
19
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution – Comprehensive Traceability
Usage example with UML “stereotype” notation
20
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Service Component <<OperationalServiceProvider>>
21
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
DoDAF Artifact Approach: Deriving the View from the Model
 The specification provides support for information needed to deliver
all DoDAF products but does not constrain users to use UML or
SysML. If the architecture can produce the needed elements, then it
is “UPDM compliant” for the view.
 The specification provides mechanisms to support export of
information to other tools, such as a project management tools.
 The specification also supports clear mechanisms for extensions of
new views as needed on projects. For example, security, logistics,
or service delivery might require additional diagrams.
 Annex B of the specification provides a non-normative overview of
strategies for delivering products based on the profile elements. The
next slide shows portions of the tables included for all artifacts.
22
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
The Artifact Guidance in the Specification: OV 5 Example
Each Artifact Has a List of Elements
UPDM Element
Significance to the View
ActivityRealization
Maps an OperationalActivity to the collection of
Systems, people, and Resources used to
implement that activity.
Effect
An Effect is an action that causes a change in the
state of some other element, such as an enemy or
physical control over space. Some approaches to
activity planning stress achieving certain
conditions, such as air supremacy or control of
strategic points. OperationalTasks and
collaborating OperationalNodes will bring about
the effect.
InformationElement
A formalized representation of information used
in an operational process. This is the type of
information used on the exchange. On activity
diagrams, the InformationElement can appear on
the input or output pins or as an activity
parameter.
InformationExchange
Materiel
23
While the InformationExchange is usually
associated with the OV-3, on the OV-5 a user can
show information exchanges between Nodes,
where the nodes appear as Activity Partitions on
the Activity Diagram.
The physical resources used to accomplish a
particular mission. In the OV-5, materiel can
include physical resources critical to mission
success.
Each Artifact Relates to Other Views
View
Relationship Details
OV-2
The activities annotating an operational Node in an OV-2 map to the
OperationalActivities described in an OV -5. Similarly, OV-5 should
document the operational Nodes that participate in each
OperationalActivity.
OV-3
An InformationExchange in OV-3 should map to one or more
information flows (an external Input, an external output, or an output
from one OperationalActivity mapped to an input to another) in OV5, if OV-5 decomposes to a level that permits such a mapping.
Above that level of decomposition, a single information flow in an
OV -5 may map to more than one InformationExchange (or none, if
the information flow does not cross Node boundaries). Note that a
physical flow is NOT represented as an information flow. A review
of physical exchanges in a model requires a custom view.
OV-6
A rule may define conditions that constrain the execution an
OperationalActivity in a specific way, or constrain the organization
or human role authorized to execute an OperationalActivity. Effects
in the OV-6b map to OperationalActivities in OV-5.
SV-5
Operational Activities in SV-5 match OperationalActivities in OV-5.
This is detailed for all artifacts and includes
examples from prototypes.
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution – Operational Activity and
System Function Link
By placing the SystemFunction inside the
OperationalActivityRealization collaboration the model has all
the information to generate the SV-5.
24
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution - V-5: An Illustration of
Exported Information
SV-5, exported from model to external tool (Excel)
Dynamic diagrams with system
element stereotyped placed in
an
OperationalActivityRealization
provide the information needed
for the SV-5
See the UPDM Specification for a more detailed review of examples and artifacts. UPDM
provides definitions of needed elements for automation, but it does not specify the
implementation of the needed model queries or transformations.
25
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution - SysML Internal Block Diagram
Compliance Level 1…Using SysML
Requirements, Problems and Rationale can be attached to any Model
Element to Trace Requirements and Capture Issues and Decisions
27
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution - OV-1 Representation
«OV-1» UCD [Tactical Targeting Mission Scenarios]
OV-1 Captures the Operational Context graphically and as Role and
Use Case models representing Mission Context, Scenarios and
enabling Capabilities
28
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution - OV-5 Representation
OV-5 Activity Diagram captures the behavior defined by OV-1 Use
Cases via Operational Activities subsequently allocated to
Operational Nodes
29
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution - OV-2 Representation
«OV-2» BDD [Operational Nodes and Needlines]
OV-2 Operational Nodes and Needlines as aggregations of allocated
Operational Activities and Information Flows respectively
30
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution - OV-3 Matrix Generation
«OV-3» Matrix [Information Exchange Matrix]
Needline ID
N1
N2
N3
N4
Info Exchange ID
IE1
IE2
IE3
IE4
Producer
Sending Op Node
Sending Op Activty
Sense Node
Sense AOI
Sense Node
Sense AOI
Command and Control Node Allocate Sensors
Command and Control Node N/A
Consumer
Receiving Op Node
Receiving Op Activity
Effects Node
N/A
Command and Control Node
Sense Node
Sense A
Effects Node
N/A
OV-3 Information Exchange Matrix auto generated based on
Operational Activity Information Flows
31
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution - OV-4 Representation
«OV-4» BDD [Operational Organization]
OV-4 Organizations and Roles allocated to each Organization are
modeled by UML Composite Structure and SysML and Block
Definition Diagrams
32
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution - OV-6a Representation
OV-6a Captures the Operational Rules allocated to Operational
model elements including Nodes, Activities, Flows, Information
Elements and States
33
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution - OV-6b Representation
OV-6b State Trace Diagram captures the Operational States and
Transitions within Operational Nodes
34
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution - OV-6c Representation
OV-6c Event Trace diagram captures the event flow (messages)
between instances of Operational Nodes…synchronized with
Operational Activities allocated to Nodes
35
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution - OV-7 Logical Information Model
«OV-7» CD [Logical Information Model]
OV-7 Defines Information Model for all Operational Information Flow elements
identified within the integrated model and viewed via OV-3 and OV-5
36
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Highlights of the solution - SV-1 Representation
«SV-1» ibd [system interconnection]
«rationale»
Customer concerned about
standards definition
See: http://standard.gov/c2
Satisfies
«requirement»
C2 Specification
Satisfies
«requirement»
Sensor Specification
:modeChange
«system»
Sensor System
«system»
C2 System
values
Mode: : states
Use of SysML requirements
and their relationships
Use of SysML flow ports and item flows
Use os SysML value
properties and units
«problem»
Legacy systems not fully
interoperable
SV-1 Provides the view of the Systems, their connections and data
flows, and allocations to Mission Scenarios and Operational Activities
37
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Background: Broad Industry, User and Vendor Support
Unified Submission Supporting Members
 Adaptive
 Lockheed Martin Corporation
 ARTiSAN Software Tools, Ltd.
 MEGA International
 ASMG
 NoMagic
 BAE Systems
 Northrop Grumman
 BCMS Consulting
 Pathfinder Solutions
 CSCI
 Raytheon Company
 EmbeddedPlus Engineering
 SAIC
 EuroStep Group AB
 Sparx Systems Pty Ltd
 General Dynamics
 Telelogic AB
 IBM
 THALES Group
38
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
UPDM – UML Profile for DoDAF and MODAF
Conclusion - The Stage is set
 Conformant specification that addresses the needs DoDAF
and MODAF
– Standards based approach will enhance tool and architecture data interoperability
– MDA™ foundation enables UPDM evolution to support DoDAF v2 and beyond as
needs evolve (e.g., SOA)
 Integrates Architecture and Engineering
– Exploitation of both UML and SysML
 Unified submission
– Supported by broad industry consortium of tool vendors and end users
 Working proof of concept
– Demonstrated at OMG workshop in March
Ready for adoption by OMG at meeting in June
39
May 16, 2007 – DoDAF Workgroup and UPDM Team Briefing
Questions?
May 16, 2007