Transcript Overview of DoDAF

Overview of DoDAF
(based on Deskbook)
Saurabh Mittal, PhD
[email protected]
Feb 17, 2005
(Last Updated, Dec 2007)
ACIMS Lab, ECE Dept.,
www.acims.arizona.edu
University of Arizona
Agenda


Definition of a Framework and an Architecture
Basic DoDAF structure




Process Flow and creation of Views


Steps involved in construction
People involved


Operational Views
System Views
Technical Views
who, how and where
Examples

SSAF (Sensing System Architectural Framework)
Architectures and Frameworks
Can the same rules help
define this architecture ?
Now consider a set of Rules,
If we have answer to this
that can define and build each of
question, then this set of Rules is
these Architectures.
called a Framework
“Extreme Architecture”: A Minimalist IT Architecture framework
Phil Robinson and Floris Gout
IT Architecture and Framework



If you can implement a drawing in ONLY one way,
then the drawing contains exact specifications for
instantiation and you have a DESIGN
If you can implement a drawing in more than one
way, you have an architecture
If you can develop more than one architecture, then
you have a framework that provides you with the
underlying structure for developing these
architectures
Clinger-Cohen’s Act’s definition of IT Architecture referring to an Integrated Framework

A framework should enable you to build specific
architectures that meet specific needs.
IT Framework Description
Department of Defense Architectural Framework (DoDAF) guidelines
• To create IT systems and architectures that cross organizational and
national boundaries
• To provide a common denominator of understanding, comparing and
integrating these Families of Systems (FoSs), System of Systems
(SoSs) and interoperating and interacting architectures
Operational
View
Identifies What needs to be
Accomplished and who does it
Systems
View
Relates Systems and Characteristics
To Operational Needs
•Specific System Capabilities
required to Satisfy
Information Exchanges
•Technical Standards Criteria
governing interoperable
Implementation/Procurement
of the selected System
capabilities
Technical
View
Prescribes Standards and
Conventions
Purpose
Critical Issues
Objectives
TradeOffs
Analysis Methods
Requirements &
Intended Use of SensorNet
Architecture
Provided by Dr. McNeill
Geographical, Functional
And Operational Bounds
Time Frame
Constraints
Contexts
Scope of Architecture
All View
Summary
Informatiion
Diagram
AV-1
The Development
Process for
Operational Views
•
•
•
•
•
•
•
OV-1
OV-5
OV-6
OV-2
OV-3
OV-7
OV-4
Operation View
Operation View
OV-1
OV-1
Created by PL and
Created by PL and
IPT Leads
IPT Leads
Operational Activity Model OV-5
Operational Concept created by
PL and IPT Leads
Determine the Information Flow
associated with Activity Set.
Identify inputs, controls, outputs
and mechanisms associated with
Activities
Operational Activity Sequence and Timing Diagrams OV-6
Supervised by IPT Leads and created by Team Members
Develop State Transition Diagrams, Internal and External Input Events
Aggregation of individual modules by IPT Leads
Develop model Repository created in this process
Operation Node
Connectivity OV-2
Created by IPT Leads
Operational
Information
Matrix OV-3
Inputs and
outputs
Logical Data Model OV-7
Created by PL and IPT
Leads (classes, objects etc)
Systems View
Systems View
Organisational
Relationship Chart
OV-4
Operational Activity Model OV-5
Identify System Functions
Identify System Functions
provided by current Systems
provided by current Systems
SV-4
SV-4
Taken from Back
Systems Function Traceability Matrix SV-5
Provides primary bridge between Operational
View and Systems View
The Development
Process for System
and Technical Views
•
•
•
•
•
•
•
•
•
•
•
•
SV-4
SV-5
SV-10
SV-11
SV-6
SV-1
SV-2
SV-7
SV-3
TV-1
TV-2
SV-8
Operational Activity Sequence and
Timing Diagrams OV-6
Taken from Back
Operation Node Connectivity OV-2
Systems State Description and System EventTrace (SV-10)
Taken From Back
Logical Data
Schema Ov-7
Taken From
Back
Systems Interface Description SV-1
Operational Information Matrix OV-3
Develop System Interfaces based on
Systems State Diagrams and Node
Connectivity
Physical Schema SV-11
Taken From Back
Manner in which OV-7 is
implemented in Real
world
System Data Exchange Matrix
SV-6
Determine How Well the
Information Flows in the system
based on OV-5, SV-5, SV-11, and
OV-7
Systems Communication Descriptions SV-2
Determine Networking Requirements
Determine networking requirements within System
Long-Haul Communications Availability
Merge the above three and FINALIZE
Technical View TV-1
Current standards
Techinical View TV-2
Systems Performance Parameters Matrix
SV-7
Future TEchnologies
Identify Hardware and Software Parameters
Systems-Systems Matrix SV-3
A matrix describing either existing
and/or required system interfaces
can be built
System Evolution Desctipiton and
System Evolution Desctipiton and
Technological advancement
Technological advancement
People Involved
DoDAF specifies this ‘hierarchy’ of people involved
in construction of the specification document and
physical realization
Abstract Description
 Planner
conceptual
DoDAF specs
Refinement
 Owner
 Designer
 Implementer
 Contractor
Realized System
System-blocks &
COTS
Organization assembly & Management
•‘Hierarchy’ is apparently just two level – Planner and Others
•Realization and Management of such massive projects would be a major issue
•Independent contractors, designers, and implementers
•Book-keeping and documentation - a critical part
Capabilities/Functionalities
Planner domain
2
Designer B
4
Contractor
9 B
Owner B
Implementer A
1
Implementer B
3
Owner A
Contractor A
5
Designer A
7
6
10
11
Contribution by Planner

Summary View
(AV-1 and OV-1)

Data centric, node-centric
and People centric
(OV-2, OV-4)

Functionality-oriented and
Motivation behind the plan
(OV-5, OV-6)

System Functionality and
traceability
(SV-5)

System Interface
Descriptions
(SV-1)
Contribution by Owner







Integrated Dictionary and terminology
(AV-2)
Operational Information Exchange
Matrix
(OV-3)
Operational Activity Model, Event-trace
and State Machines
(OV-5, OV-6b,c)
System Interface Description
(SV-1)
Operational to System Traceability
Matrix
(SV-5)
System-system matrix
(SV-3)
System Evolution description
(SV-8)
Refines the Operational Concepts constructed by the Planner
Ensures that functionality desired is feasible
Provides detailed ‘operational’ views
Develops the transition to System Views
Contribution by Designer








Logical Connectivity
(OV-7)
System Communication
description
(SV-2)
System Functionality
description
(SV-4)
System data-exchange
matrix
(SV-6)
Performance parameters
matrix
(SV-7)
System evolution
(SV-8)
System Rules, Event-traces
and State transitions
(SV-10a,b,c)
Technical Standards Profile
(TV-1)
More so like the Planner… but in ‘Systems’ domain.
He actually merges the Operational concepts constructed by the
Planner and puts them in systems perspective
Verifies the operational functionality based on the Logical Node
description document (OV-7)
Contribution by Implementer
Refines the System Views handed over by the Designer
Verifies the System functionality with Operational functionality description
using Node Connectivity document (OV-7)
Maps it to current technology
Develops the migration and evolution pathway towards future



System Technology Forecast
(SV-9)
Physical Schema
(SV-11)
Technical Standards Forecast
(TV-2)
Contribution by Contractor
Takes money… for supply and installation of equipment
Refines the System-View docs on need basis and documents it
Designer’s work is realized here
May result in refinement of ‘design’ itself



Installation
Field Testing
Support...etc..etc...etc…
Example
SSAF – A subset of DoDAF
(Sensing System Architectural Framework)

Please refer to link below:
http://www.u.arizona.edu/%7Esaurabh/ILS3Docs/ILS3%20Architecture%20Based%20On%20DoDAF.ppt
Published Research 2005-2007

Saurabh Mittal, Bernard P. Zeigler, Modeling and Simulation for Systems of Systems Engineering,
Chapter for “Systems of Systems Engineering for 21st Century”, Editor Mo Jamshidi, Wiley, to appear

J.2: Saurabh Mittal, Eddie Mak, James J. Nutaro, DEVS-Based Dynamic Model Reconfiguration and
Simulation Control to in the Enhanced DoDAF Design Process, Journal of Defense Modeling and
Simulation (JDMS), Vol. III No. 4, 2006

J.1: Saurabh Mittal, Extending DoDAF to Allow DEVS-based Modeling and Simulation, Special issue on
DoDAF, Journal of Defense Modeling and Simulation JDMS, Vol. III No. 2, 2006

C.3: Saurabh Mittal, José Luis Risco Martín, Bernard P. Zeigler, DEVS-Based Web Services for Netcentric T&E, Summer Computer Simulation Conference (SCSC’07), San Diego, July 2007

C.2: Saurabh Mittal, Amit Mitra, Amar Gupta, Bernard P. Zeigler, Strengthening OV-6a Semantics with
Rule-Based Meta-models in DEVS/DoDAF Based Life-cycle Architecture Development, IEEEInformation Reuse and Integration (IRI06) Conference, Special section on DoDAF, Hawaii
September2006

C.1: Bernard P. Zeigler, Saurabh Mittal, Enhancing DoDAF with a DEVS-based System Lifecycle
Development Process, In Proceedings of IEEE International Conference on Systems, Man and
Cybernetics, SMC05, Hawaii 2005