Integrating UPDM with
SysML and UML on a
DoD Acquisition
Program
OMG UAF & MBSE Information Day
March 23, 2015
Paul Vaughan
NGIS Tech Fellow
Chief Engineer/Architect
DoD and ISR Acquisition Programs
•  DoD and ISR programs typically require extensive and detailed traceability
–  Requirements flowdown and derivation down to software item/hardware item (SI/HI)
–  Functional flow block diagrams (activity diagrams/sequence diagrams/internal block diagrams) down to unit level
–  Requirements allocated to architectural elements (physical baseline) and system functions (functional baseline), including
performance requirements
–  Contractor’s functional baseline, verification environments, and operations concepts are traceable to and consistent with
the Government’s CONOPS
–  Test & evaluation planning is traceable to critical design, correlating test objectives, test environments, and test resources
to allocated requirements
•  Most programs require diagrams compliant with the DoD Architecture Framework (DoDAF)
–  Generally the Government doesn’t specify to what level this applies: usually interpreted as at the top level of the contract
scope (system or segment level)
•  The Systems Engineering team is responsible for the development of requirements, definition of the
functions, and creation of the architectural design that provide the content for these diagrams
•  The Software/Hardware teams are responsible for detailed designs consistent with higher level
designs and that are fully traceable to Government requirements and CONOPS
•  An objective of Model-Based methods is to do all that (and more) in a single integrated model
2
Operational Context is provided by System
Spec and CONOPS from Government
I/F
Stakeholder Requirements
Definition
• Identify users and stakeholders
• Define needs
• Capture source requirements
• Initialize requirements database
• Establish the CONOPS
• Generate System Requirements
Document
I/F
Req
1
Req
11
Requirements Analysis
Architectural Design
• Define selection criteria
• Define/refine system element alternatives
• Synthesize multiple system architectures
• Analyze and select preferred system architecture/
element solution
• Model, simulate, and prototype system architectures
• Define, refine and integrate system physical
configuration
• Implement requirements and design feedback loops
I/F
Req
12
I/F
• Define systems capabilities and performance
objectives
• Define, derive, and refine functional/performance
requirements
• Define other non-functional requirements
• Develop specification trees and specifications
• Allocate requirements and establish traceability
• Generate a system specification
3
I/F
Sys
Act
a1
Act
a 11
I/F
Req
2
Req
21
Act
a 12
Act
a2
Req
22
I/F
Sys
I/F
I/F
I/F
Act
a 31
Act
a3
I/F
Act
a 32
Operational Context in Model
(User requirements and OV-5b)
Systems Engineering Provides the System
Design Model, Including Traceability to OpsCon
I/F
Stakeholder Requirements
Definition
• Identify users and stakeholders
• Define needs
• Capture source requirements
• Initialize requirements database
• Establish the CONOPS
• Generate System Requirements
Document
I/F
Req
1
Req
11
Requirements Analysis
Architectural Design
• Define selection criteria
• Define/refine system element alternatives
• Synthesize multiple system architectures
• Analyze and select preferred system architecture/
element solution
• Model, simulate, and prototype system architectures
• Define, refine and integrate system physical
configuration
• Implement requirements and design feedback loops
I/F
Req
12
I/F
• Define systems capabilities and performance
objectives
• Define, derive, and refine functional/performance
requirements
• Define other non-functional requirements
• Develop specification trees and specifications
• Allocate requirements and establish traceability
• Generate a system specification
4
I/F
Sys
Func
1
Func
11
I/F
Req
2
Req
21
Func
2
Func
12
I/F
I/F
Func
31
I/F
Sub
2
Comp
21
I/F
Comp
22
Func
3
I/F
I/F
Sys
Sub
1
Req
22
I/F
Sys
I/F
I/F
I/F
I/F
Sub
3
Comp
23
Func
32
Software Traces the System Engineering
Design into the Software
System Engineering Design
I/F
Sys
I/F
Req
1
Req
11
I/F
Req
12
I/F
I/F
Req
21
I/F
Func
1
Req
22
Func
11
I/F
I/F
Req
22
I/F
Req
2
Sys
Req
11
Req
21
I/F
Func
31
Req
32
Func
41
I/F
Func
2
Func
12
I/F
Req
12
Req
31
I/F
I/F
I/F
Func
21
Func
42
Func
32
Func
3
I/F
Sub
1
Func
22
I/F
Sys
I/F
I/F
I/F
Sys
I/F
Func
51
Sub
11
Func
52
Software/Hardware Design
5
I/F
I/F
I/F
Func
33
I/F
Comp
21
Comp
41
I/F
Sys
Sub
2
Comp
22
I/F
I/F
I/F
Sub
12
Comp
42
Comp
23
I/F
Sys
I/F
Sub
3
I/F
I/F
Sub
13
Comp
43
System and Software Design With Full
Traceability in an Integrated Model
•  System requirements are decomposed into lower level specs
and are traceable to the software and hardware designs
•  CONOPS (operational activities) are traceable to software
and hardware behavior in use case, activity, state, and
sequence diagrams
•  Requirements at each architecture level are allocated to SW/
HW components and functions (activities)
•  So have we achieved the objective?
•  Along the way there was some creative modeling to make
this happen
–  System level items modeled in DoDAF (UPDM or SysML) per
customer requirement
–  Software items modeled in UML due to SW team familiarity with UML
and (in some programs) desire to generate code from model
–  DoDAF model items aren’t typically allowed on SysML diagrams
–  Had to transition from DoDAF to UML by switching tools or building a
transition layer
6
One Model, Multiple Viewpoints
Typical Architecture Synthesis Overview
System
Segment
Element
Segment
Requirements
Satisfies
Mission
Threads
(OV-5b)
Segment
Activity
Diagrams
(SV-4)
Segment to
Externals
Structure
(SV-1, SV-2)
Element
Requirements
Satisfies
Allocated
Performed to
by
Element
Activity
Diagram
(SV-4)
Decomposed to
Implemented
by (SV-5a)
OV-1a,
OV-2,
OV-4,
OV-6c,
AV-1, AV-2
Allocated
to
Performed
by
Element to
Element
Structure
Diagrams
(SV-2,
BDD, IBD)
Decomposed to
Refined
by
Refined
by
Use Case
Diagrams
[critical
only]
SV-6,
StdV-1
SI/HI Component
SW/HW Unit
Software
Requirements
Satisfies
Performed
by
Component
to
Component
Activity
Diagrams
Allocated to
Allocated
to
Component
to
Component
IBD/BDD
Performed
by
Packaged
as
SW IntraComponent
Sequence
Diagrams
[Reuse SW:
as needed]
Decomposed
to
Refined
Refined
by
by
Composed
into
Refined
by
Component
to
Component
Sequence
Diagrams
[as needed]
SI to SI
Sequence
Diagrams
[as needed]
SW Class
Diagrams
and Class
Descriptions
CSU
Blocks
(IBD/
Package
Diagrams)
SW State
Machine
Diagrams
[as needed]
Deployment
Diagrams
Implemented by
SEIT IPT Leads
Software/Hardware IPT Leads
SEIT & Software/Hardware Shared
Responsibility
Requirements [Imported
from DOORS]
System
View
Segment
View
Element
View
SI Component
View
SW Unit
View
Linked in the
Architecture Model
Traced in the Design
Assurance Matrix (DAM)
Decomposition of requirements and structural items not shown but are similar to activity decomposition
SEIT and Software/Hardware IPTs Share Ownership of Architecture and Design
7
Architecture Synthesis Overview
System
Segment
Element
SI Component
Segment
Requirements
Satisfies
Mission
Threads
(OV-5b)
Allocated
to
Performed
by
Segment
Activity
Diagrams
(SV-4)
Satisfies
Allocated
Performed to
by
Element to
Element
Structure
Diagrams
(SV-2,
BDD, IBD)
Element
Activity
Diagram
(SV-4)
Decomposed to
Implemented
by (SV-5a)
OV-1a,
OV-2,
OV-4,
OV-6c,
AV-1, AV-2
Segment to
Externals
Structure
(SV-1, SV-2)
Element
Requirements
Decomposed to
Refined
by
Refined
by
Use Case
Diagrams
[critical
only]
SV-6,
StdV-1
SW Unit
Software
Requirements
Satisfies
Performed
by
Component
to
Component
Activity
Diagrams
Allocated
to
Component
to
Component
IBD/BDD
Decomposed
to
Refined
Refined
by
by
Component
to
Component
Sequence
Diagrams
[as needed]
SI to SI
Sequence
Diagrams
[as needed]
Allocated to
CSU
Blocks
(IBD/
Package
Diagrams)
Performed
by
Packaged
as
SW IntraComponent
Sequence
Diagrams
[Reuse SW:
as needed]
SW Class
Diagrams
and Class
Descriptions
Composed
into
Refined
by
SW State
Machine
Diagrams
[as needed]
Deployment
Diagrams
Implemented by
SEIT IPT Leads
Software/Hardware IPT Leads
SEIT & Software/Hardware Shared
Responsibility
SW Unit
Linked in the
in the Design
Transition
Layer
in Traced
View
Artisan
Model
Assurance Matrix (DAM)
Decomposition of requirements and structural items not shown but are similar to activity decompositionone of these levels
Requirements [Imported
into Artisan from DOORS]
System
View
Segment
View
Element
View
SI Component
View
Transition Layer Bridges Between SEIT and Software/Hardware Parts of Model
8
Conclusions
•  Objective of full traceability from
system to software is achievable but
faces hurdles
•  A single model can support both
SEIT and SW/HW objectives
•  Current architecture modeling tools
don’t consistently provide a good
solution
•  UPDM and/or SysML may need
revision to facilitate better
traceability, or is it a tool
implementation issue?
9
One Model, Multiple Viewpoints