Application of the DoDAF to Generalized Software

Transcription

Application of the DoDAF to
Generalized Software
Presented by
Jeremy Asbill
Chief Software Architect
Agenda
• Review the DoDAF and its intent.
• Identify potential benefits of applying the
DoDAF to generalized software
• Present our experience applying the DoDAF in
this capacity.
– We have applied the DoDAF to a general
technology developed for the Air Force.
– We have applied the DoDAF to an application of
that technology.
What is the DoDAF?
• Department of Defense Architectural
Framework.
• From [DODAF1, 2004]:
– “…defines a common approach for DoD
architecture description development, presentation,
and integration...”
– “…intended to ensure that architecture
descriptions can be compared and related across
organizational boundaries…”
DoDAF Views
• All View (AV)
– The AV wraps the architecture up, capturing architecture
information that does not belong in other views.
• Operational View (OV)
– The OV is essentially a domain description.
• Systems View (SV)
– The SV describes the systems an interconnections that are
pertinent to the domain described in the operational view.
• Technical Standards View (TV)
– The TV captures the set of “rules governing the
arrangement, interaction, and interdependence of system
parts or elements.” [DODAF1, 2004]
DoDAF Products
• All View
– AV-1 : Overview and Summary Information
– AV-2 : Integrated Dictionary
• Operational View
–
–
–
–
–
–
–
OV-1 : High-Level Operational Concept Graphic
OV-2 : Operational Node Connectivity Description
OV-3 : Operational Information Exchange Matrix
OV-4 : Organizational Relationships Chart
OV-5 : Operational Activity Model
OV-6 : Operational Activity Sequence and Timing Descriptions
OV-7 : Logical Data Model
DoDAF Products (cont’d)
• System View
–
–
–
–
–
–
–
–
–
–
–
SV-1 : System Interface Description
SV-2 : Systems Communication Description
SV-3 : Systems-Systems Matrix
SV-4 : Systems Functionality Description
SV-5 : Operational Activity to Systems Function Traceability Matrix
SV-6 : Systems Data Exchange Matrix
SV-7 : Systems Performance Parameters Matrix
SV-8 : Systems Evolution Description
SV-9 : Systems Technology Forecast
SV-10 : Systems Functionality Sequence and Timing Description
SV-11 : Physical Schema
• Technical View
– TV-1 : Technical Standards Profile
– TV-2 : Technical Standards Forecast
Product Usage Table
z

†
Blank
=
Product is highly applicable
=
Product is often or partially applicable
=
=
=
Product is specifically addressed in policy
Product is required for an integrated architecture
Product is usually not applicable
APPLICABLE ARCHITECTURE PRODUCTS
All View
1
Operational View (OV)
2
1
2
3
4
5
6
Tech Stds
View
Systems View (SV)
7
1
2
3
4
5
6
7
8
9
10
11
1
2
RECOMMENDED USES OF ARCHITECTURE:
Planning, Programming, Budgeting, Execution Process
Capability-Based Analysis for IT Investment Decisions
Modernization Planning and Technology Insertion/Evolution
Portfolio Management
z z z z z z z z z z z z z z z z z
z z z z
z z z z z
z z
z
z
z
z
z
z
z z

z z z z z z
z z z z z
z z
z z z z
z z

z

Joint Capabilities Integration and Development System
JCIDS Analysis (FAA, FNA, FSA)
ICD/CDD/CPD/CRD
Analysis of Alternatives (AOA)
z
z
z z z z z
z z z
Acquisition Process
Acquisition Strategy
C4ISP
System Design and Development
Interoperability and Supportability of NSS and IT Systems
Integrated Test & Evaluation
z
z
z
z
z
z z z
z
z z z z
z
z
z z
z
z z z z z
z
z z z

z
z
z
z

z z z z z z
z z z
z z z z z z
z
z
z
z
z
z
z
z
z
z
z
z
z z
z
z
z
z
z

z
z
z
z
z
z

z
z z z
z z
z
z z
Operations (Assessment, Planning, Execution, …)
Operations Planning & Execution
CONOPS & TTP
Communications Plans
Exercise Planning & Execution
Organizational Design
BPR/FPI
†
This table is taken directly from Figure 3-7 in [DoDAF1, 2004]
z
z
z
z
z

z
z
z
z
z
z
z z z
z z z

z z z
z z z
z z z
z z

z

DoDAF Product Focus
• Our focus has been on system design and
development, so we have spent time with the
following products:
–
–
–
–
AV-1, AV-2
OV-2, OV-3, OV-5, OV-6
SV-1, SV-2, SV-3, SV-4, SV-5, SV-6, SV-7, SV-8
TV-1
• Furthermore, we have had little to no success in
finding enough information about All-CADM.
– Our work with AV-2 has been limited at best.
– We have made every effort to enable All-CADM with the
information that we do have.
Notations Used
• We strive to use the UML wherever it makes sense.
• The OMG is working on a UML Profile for DoDAF
[OMG,2005], but until that is done we have created
our own profile:
–
–
–
–
–
OV-2 :
OV-5 :
OV-6:
SV-1 :
SV-4 :
Communication Diagrams
Activity Diagrams
State Machines and Interaction Diagrams
Component Diagrams
Use Case Diagrams, Activity Diagrams, and
Class Diagrams
DoDAF is for Specialized Software
• DoDAF has been designed to describe specific
applications that target specific missions.
• This design supports a major intent of the
DoDAF: to allow the DoD to compare IT
systems and their uses.
• However, not all software developed by/for the
DoD targets a specific mission or set of
missions.
Example: Avenue
• The PARIS/SELDI program at Hill AFB has
developed Avenue, a generalized, repository
technology with which several data repository
applications have been implemented.
• While the DoDAF can readily be applied to the
repository applications, doing so requires redundant
information about the core technology in each
architectural description.
• Instead, we have first applied the DoDAF to Avenue
and then leveraged that in applying the DoDAF to
Avenue applications.
Generalized Operational View
• Typically, an operational view (OV) is a
domain description for one or more specific
DoD missions.
• However, generalized software is developed to
apply to various DoD missions (maybe more).
• For generalized software, the OV should
define a “Domain Pattern”.
Domain Pattern
• A domain pattern defines the set of domains to
which the generalized software may be
applied.
• A domain pattern is just like a domain
descriptions except:
– Operational concepts such as nodes, needlines, and
activities are artificial.
– Attributes of such artificial elements are ranges of
acceptable “values” for those attributes.
Artificial Operational Concepts
Avenue OV-2
comm Active Distribution
3: document(s)
producer
:Business Participant
consumer
1: request for
document(s)
Operational
Nodes
2: document(s)
publisher :Custodian
Needlines
2.1: document(s) &
update information
:Data Repository
Artificial Operational Concepts
Avenue OV-5
Operational
Nodes
Flows
Operational
Activities
Attribute Ranges
Avenue OV-3
Information Exchange – Locate Document(s)
This information exchange consists of data published (1 or more
documents) in the data repository and is recovered from the repository by
a librarian for delivery to another party.
…
Performance Attributes
• This exchange may occur 0-100 times per day.
• Upper bound on time required is a function of the size of the
exchanged information elements. Utr = network bandwidth + 1
second/Megabyte
Information Assurance & Security
• The receiving party is authenticated via user identification and
password.
• It must be possible to complete this information exchange 100% of the
time during the receiving node’s operating hours.
• The identity of the receiving party must be verified before delivery of
the information.
…
Periodicity
Timeliness
Access Control
Availability
Confidentiality
Generalized System View
• The system view will also describe a pattern.
– The pattern must be acceptable if the generalized
software is to be used for a specific application.
– The pattern also serves to instruct the application
developer on what they must do to construct an
application using the generalized system.
– Reduces the amount of description (especially
functionality) required in the application
architecture description.
– Provides performance parameters to allow
applicability assessment.
Application Pattern
Avenue SV-1
Concrete
Systems/Interfaces
Classifiers of
application specific
systems/interfaces
Re-Usable Functionality Descriptions
Avenue SV-4
Enumerates
Provided
Functionality
Describes and
Decomposes
Functionality
Re-Usable Functionality Descriptions
Avenue
SV-4
Provides static
context for
activity
diagrams.
Performance Parameters
Avenue SV-6
System Data Exchange – Provide IST List
…
Information Assurance
•
•
•
•
•
•
•
…
Access Control. This data exchange can only occur within the context of a valid, non-expired session
key. Session keys are granted via user name/password authentication.
Availability. Avenue supports applications in which 24/7 availability is required. Avenue also
assumes that some of this availability burden will be addressed by the administration of the Avenue
Server host.
Confidentiality. Avenue enables, but does not require, encryption (via SSL) for this data exchange.
Dissemination Control. Avenue currently assumes that dissemination control will be implemented in
applications. For example, the MFRS restricts access to historical data to those user’s stationed at
Hill AFB.
Integrity. There are no integrity checks implemented for this data exchange by Avenue. The
underlying transport (i.e. TCP/IP) may implement integrity checks.
Non-Repudiation Producer. Avenue enables, but does not require, server authentication (via SSL) for
this data exchange.
Non-Repudiation Consumer. See Access Control above.
Summary: Generalization
• DoDAF can be used to describe general purpose
software so its applicability can be assessed.
– Operational View defines a “Domain Pattern”
• Model operational concepts not specific operational occurrences
• Provide ranges and sets for DoDAF entity attributes and properties
rather than specific values
– System View defines a “System Pattern”
• Provides guidance for when to use the generalized system
• Provides guidance on how to use the generalized system
• Reduces effort needed for architecture description
Example Application: MFRS
• The PARIS/SELDI program at Hill AFB has
developed multiple applications using Avenue.
• The Master Folder Repository System (MFRS)
has been in production for several years and is
used primarily by OO-ALC (HAFB) and DLA.
• The Avenue OV and SV can be consulted to
see that Avenue is a suitable MFRS platform.
• The MFRS architecture descriptions has been
largely developed in terms of the Avenue
architecture description.
MFRS Operational View
• MFRS OV-2 and OV-3 do not reference the
Avenue OV-2 and OV-3.
• Rather, they provide the basis for mapping the
MFRS domain to the Avenue domain pattern.
• Other MFRS OV products are written in terms
of Avenue OV products.
Map Domain to Pattern
comm Active Distribution
3: document(s)
producer
consumer
1: request for
document(s)
2: document(s)
2.1: document(s) &
update information
:Data Repository
Avenue OV-2
MFRS OV-2
MFRS OV in Avenue Terms
Avenue OV-5
MFRS OV-5
Entity Type
Avenue Entity Name
MFRS Entity Name
Operational Node
(Partition)
consumer :Business
Participant
consumer :Item Manager
Operational Node
(Partition)
producer :Business Participant
producer: Screening Team
Operational Node
(Partition)
publisher: Screener
Operational Activity
Realization of Need
Item
Management/Forecasting
Use Data
PR Processing
Produce Data
Screening
Publish Data
Master Folder Publishing
MFRS System View
• Avenue SV is used as a template.
• MFRS SV extends Avenue functionality or
adds new functionality.
• MFRS SV only supplies information not
already provided by the Avenue SV.
Arch. Description Template
Avenue SV-1
Consumer Business
Applications
Producer Business
Applications
MFRS SV-1
Repository
Maintenance Tools
Add or Extend Functionality
MFRS SV-4
Avenue SV-4
MFRS extends the Avenue “Remove
IST” activity to provide the “Remove
Master Folder” activity.
Technical Standards View
• Application of the Technical Standards View
(TV) to generalized software is trivial.
• Applications of the generalized software
inherit TV properties from the generalized
software.
All-CADM and DARS
• We have not addressed the All-CADM or
DARS in this work.
• We have been unable to acquire sufficient
information to fully understand the AllCADM.
• We do believe that modifications and/or
enhancements to the All-CADM would be
required to fully support architecture
descriptions for generalized software.
Summary
• While the DoDAF has been designed to target
mission specific software, it can be used to describe
generalized software so its applicability can be
assessed.
• An architecture description for general purpose
software provides:
– A “domain pattern” that can be used to assess the
applicability of general purpose software to a specific
mission.
– A “system pattern” that can be used as guidance in defining
the mission specific architecture.
– Reduction in effort required to author a mission specific
architecture.
References
[DODAF1, 2004] DoD Architecture Framework Version 1.0, Volume1: Definitions and Guidelines, DoD
Architecture Framework Working Group, February 2004.
[DODAF2, 2004] DoD Architecture Framework Version 1.0, Volume2: Product Descriptions, DoD
Architecture Framework Working Group, February 2004.
[OMG, 2005] UML Profile for DODAF/MODAF Website, http://syseng.omg.org/UPDM.htm, Object
Modeling Group (OMG), 2005
[UML, 2005] The Unified Modeling Language Reference Manual, Second Edition, James Rumbaugh, Ivar
Jacobson, Grady Booch, Addison-Wesley Object Technology Series, 2005,
ISBN 0-321-24562-8
[Wisnosky, 2005] DoDAF Wizdom, Dennis E. Wisnosky, Joseph Vogel, et. al., Wizdom Press,
2004-2005, ISBN 1-893990-09-5
Acronyms
AFB
Air Force Base
All CADM All DoD Core
Architecture Data Model
API
Application Programming
Interface
AV
All View
DARS DoD Architecture Repository
System
DLA
Defense Logistics Agency
DoD
Department of Defense
DoDAF DoD Architecture Framework
ESA
Engineering Support Authority
HAFB Hill Air Force Base
IST
Integral Sub-Tree
MFRS Master Folder Repository
System
MoDAF Ministry of Defense
Architecture Framework (UK)
OMG
Object Modeling Group
OO-ALC Ogden Air Logistics Center
OV
Operational View
PARIS Part And Repair Item Support
SELDI Science, Engineering, and
Laboratory Data Integration
SPARES Spare PArt REprocurement
System
SSL
Secure Socket Layer
SV
System View
TCP/IP Transport Control
Protocol/Internet Protocol
TDP
Technical Data Package
TV
Technical View
UML
Unified Modeling Language
UPDM UML Profile for DoDAF and
MoDAF