Download - PowerPoint Presentation (size=2.73MB)
© 2002 The MITRE Corporation. All rights reserved.
DoD Architecture Framework DoD Architecture Framework V 1.0 V 1.0
Dr. Fatma Dandashi
The MITRE Corporation
April 8, 2003
Ope
ratio
nal System
s
Technical
2 © 2002 The MITRE Corporation. All rights reserved.
Context and Relationship To This AudienceContext and Relationship To This Audience
Manufacturing Manufacturing (Hardware Parts)(Hardware Parts)
AP233AP233
Systems Systems EngineeringEngineering
Processes and Processes and Modeling StandardsModeling Standards
Mission Needs/Mission Needs/Information Interoperability Information Interoperability
RequirementsRequirements
Software Parts/Software Parts/InformationInformation
UML/XMIUML/XMI
Industry StandardsIndustry Standards
Ope
ratio
nal System
s
Technical
Systems of SystemsSystems of Systems(Software Intensive)(Software Intensive)
3 © 2002 The MITRE Corporation. All rights reserved.
Architecture DefinedArchitecture Defined
Architecture
"An architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” IEEE STD 1471-2000
Architecture Description– Graphical, tabular or textual representations of the architecture
Architecture Discipline– A discipline for developing and analyzing an architecture in terms of
its processes, components, and their relationships and rules.
ArchitectureArchitectureArchitectureArchitecture ==Structure ofStructure ofComponentsComponentsStructure ofStructure ofComponentsComponents
RelationshipsRelationshipsRelationshipsRelationshipsPrinciples &Principles &GuidelinesGuidelines
Principles &Principles &GuidelinesGuidelines++ ++
4 © 2002 The MITRE Corporation. All rights reserved.
Why Architecture?Why Architecture?
Architecture is about structure and relationships– Making things fit together and work together well
Architecture is about Categories to identify and clarify, facilitate reuse, eliminate redundant efforts
Economy Demands
- Things Fit Together And Work Well With Minimal Investment,
- Taking Advantage Of Reuse, And
- Eliminating Unnecessary Redundant Efforts
5 © 2002 The MITRE Corporation. All rights reserved.
Parallel RevolutionsParallel Revolutions
InformationRevolution
1985 86 87 88 89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 …
• Widespread E-Commerce • Wideband Internet to Homes
• Apple Personal Computer
• Internet Goes ‘Public’
• Low Cost Cell Phone Service
• Windows95
• Windows98
• Windows2000/XP
U.S.Dept of Defense
1985 86 87 88 89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 …
• PPBS Process Changes?• Capabilities-Based Acquisition?• …???• Goldwater-Nichols Act
• DARPA Focuses on Infotech
• Strategic Defense Initiative • Joint Force in
Gulf War
• JV2010 – Integrated Defense Strategy
• Joint Staff BeginsArchitecture Focus
• JFCOM Formed• C4ISR AF • JV2020
• TerrorismStrikes US
(9/11)
• Dept of Homeland Security• DOD 5000 Acquisition Reformed• DoDAF Version 1 Required• DAB Reviews JMA• CJSCI 3170 (Draft)
• Clinger-Cohen Act
• Digital Wireless Phones Introduced
• End of the Soviet Empire • ‘Fall of the Wall’
6 © 2002 The MITRE Corporation. All rights reserved.
• Agency or battlefield must work together• Must integrate many business processes, data flows, much
infrastructure• Need a description and structure of how to work together• Need integrated set of products to capture relationships for
understanding and analysis• Need to assess dependencies and impacts
Systems of Systems Agency Cross Agency
- Must have architecture, To document/ analyze interfaces
- Assess impacts and dependencies
- How agency achieves mission,- what are priorities
- Use architecture for how sharing, intertwined processes, communications occur
- Assess impacts and dependencies
- Use reference models to identify similar functions, efforts, potential joint work;
- Use architecture for how sharing, intertwined processes, communications occur
Need for Integrated Architecture Descriptive Need for Integrated Architecture Descriptive ProductsProducts
7 © 2002 The MITRE Corporation. All rights reserved.
Policy and Guidance on Architecture – Policy and Guidance on Architecture – Mandate for ArchitecturesMandate for Architectures
Information Technology Management Reform Act (ITMRA)/Clinger-Cohen Act. (1996) Mandates that Chief Information Officers of Executive Agencies are responsible for “developing, maintaining, and facilitating the implementation of a sound and integrated information technology architecture for the executive agency “.
Executive Order 13011: Federal Information Technology (1996). Executive Agencies shall appoint a Chief Information Officer and “shall refocus information technology management to support directly their strategic missions, implement an investment review process that drives budget formulation and execution for information systems, and rethink and restructure the way they perform their functions before investing in information technology to support that work.”
Chief Information Officer of the Department of Defense. Review and provide recommendations to the Secretary of Defense on Department of Defense budget requests for information technology and national security systems.
8 © 2002 The MITRE Corporation. All rights reserved.
DoD Policy on Using ArchitecturesDoD Policy on Using Architectures
DoDD 4630.5, Interoperability and Supportability of Information Technology (IT) and National Security Systems, January 11, 2002
DoDI 4630.8, Interoperability and Supportability of Information Technology (IT) and National Security Systems, May 2, 2002
DoDD 8000.1, Management of DoD Information Resources and Information Technology, February 27, 2002
DoDD 8100.01, Global Information Grid Overarching Policy, September 19, 2002
DoDI 5000.2, Operations of the Defense Acquisition System, draft October 2002
CJCSI 3170.01C, Joint Capabilities Integration and Development System, draft 2003 (Replacement for Requirements Generations System)
Recent DoD policy highlights use of architectures for:– Understanding the DoD as an enterprise– Identification of operational requirements– Rationalization of IT investment decisions– Improvements to interoperability among various systems
9 © 2002 The MITRE Corporation. All rights reserved.
Policy Enabled by Common Approach for Policy Enabled by Common Approach for Developing ArchitecturesDeveloping Architectures
DoD Architecture Framework (DODAF)Common approach for developing an architecture description
Core Architecture Data Model (CADM)
Common data model for architecture data
DoD Architecture Repository System (DARS)
Common repository for storing and retrieving architecture data
DoD Guidance on Developing Architectures
10
© 2002 The MITRE Corporation. All rights reserved.
Increased Emphasis on Meta-Data Increased Emphasis on Meta-Data StandardizationStandardization
Each DODAF product description– Information Element Definition Table– CADM Support
Core Architecture Data Model (CADM)– Build Architectures IAW CADM
DoD Architecture Data Repository (DARS)– CADM compliant data repository – Hosts accredited DoD architecture information
11
© 2002 The MITRE Corporation. All rights reserved.
DODAF Core Data ElementsDODAF Core Data Elements
Technologies
InformationData
Performance
Standards
Systems
Operational Activities
Systems Nodes
Operational Nodes
System Functions
Facilities,Locations,Units, and Platforms
DODAF Product data Elements, CADM DODAF Product data Elements, CADM Model, & Basis for DARS SchemaModel, & Basis for DARS Schema
12
© 2002 The MITRE Corporation. All rights reserved.
* CADM is a database design for architecture data* Products convey relationship between architecture data elements
System Functions
Business (Organization) Nodes
Systems (Location) Nodes
Business Activities
Systems
Standards
Performance
Data Information
Technologies
CADM Schema of Product field contents
Activity Model
Systems Interface
Description
DODAF Product
DODAF Arch Data
Element
Core Architecture Data Model (CADM)Core Architecture Data Model (CADM)
13
© 2002 The MITRE Corporation. All rights reserved.
DARS ArchitectureDARS Architecture
TCP/IP Port 1521
Tape back-up
Oracle 9.2Database
Server Tape back-up
OracleInternet
ApplicationServer
R2 w/ Oracle Portal
FIREWALL
Desktop withInternet ExplorerModeling Tools
(System Architect)
Desktop withInternet ExplorerModeling Tools
(SLATE)
Desktop withInternet Explorer
Modeling Tools (ROSE)
HTTP Port 443
Various Users, Various Users, Various Modeling ToolsVarious Modeling Tools
Architecture Data, Architecture Data, CADM SchemaCADM Schema
14
© 2002 The MITRE Corporation. All rights reserved.
Benefits of Architecture Meta-Data Benefits of Architecture Meta-Data StandardizationStandardization
Reuse of data
Consistency that facilitates integration
Flexibility in partitioning of data from different points of view
Ability to use automated architecture and modeling tools interchangeably
Better support for analysis and decision-making
Increased emphasis on development of integrated architectures
De-emphasis of an architecture product-by-product approach
15
© 2002 The MITRE Corporation. All rights reserved.
DistributedArchitecture Development
in accordance with Results in ...
• Assures that architectures are integratable across the community• Establishes threads that tie the architecture views together• Provides the basis for an audit trail that relates systems to measures of mission effectiveness
Joint Mission Areas
Joint Mission Areas
NEO JTF
NIMA
Targeting/BDA
AFTaskForce
Integratable architectures that exploit opportunities for
integrated, interoperable, and cost-effective capabilities
Developing a DoD Enterprise ArchitectureDeveloping a DoD Enterprise Architecture
Operational
Syst
ems
Technical
Framework
DARS - Repository
CADM – Data ModelJoint
Mission Areas
AFTaskForce
Targeting& BDA
TacticalInternet
MilitaryService
NEO JTF
CC
NIMA
Global Information
Grid
ICNational
Theater
CJTF
Tactical
CC
TacticalInternet
Global Information
Grid
IC
MilitaryService
16
© 2002 The MITRE Corporation. All rights reserved.
DoD Architecture FrameworkDoD Architecture Framework
The Department of Defense (DoD) Architecture Framework (DODAF)
– Defines a standard approach for describing, presenting, and integrating DoD architectures
The principal objective of the Framework is to – Ensure that architecture descriptions can be compared and related
across organizational boundaries, including Joint and multi-national boundaries
17
© 2002 The MITRE Corporation. All rights reserved.
DoD Architecture FrameworkDoD Architecture Framework
DODAF is partitioned into – Volume I: Definitions, guidelines, and background material
Designed for managers
– Volume II: Descriptions of products Designed for architects and engineers
– Deskbook: Supplementary material (How to) guidance on architecture development and use Designed for engineers
Expected Release – June 2003
Available on the Web– http://flrc.mitre.org/dodfw/
18
© 2002 The MITRE Corporation. All rights reserved.
Systems
Basic Principles - An Integrated Architecture Basic Principles - An Integrated Architecture with Three Viewswith Three Views
Information Flow
OperationalNodes
Data Flow
Communications
Prescribes Technical Standards
TechnicalStandards View
Standards
Services
Activities/Tasks
• Specific Capabilities Required to SatisfyInformation Exchanges
• Technical Criteria GoverningInteroperable Implementation/Procurement of the SelectedSystem Capabilities
•Basic Technology
Supportability
•New Technical Capabilities
•W
hat N
eeds
to B
e
Done
•W
ho D
oes It
•In
form
atio
n Ex
chan
ges
Requ
ired
to G
et It
Done
Identifies Participant Relationships
And Information Needs
Operational View
X YX
Z
XY
Y
Relates Systems Capabilities to Operational Requirements
SystemsView
•Operational Capability
Requirements
Service Areas
•Sy
stem
s th
at S
uppo
rt
the
Activ
ities
and
Info
rmat
ion
Exch
ange
s
19
© 2002 The MITRE Corporation. All rights reserved.
Basic Principles - Graphic, Textual, and Tabular Basic Principles - Graphic, Textual, and Tabular ProductsProducts
Operational
Syst
ems
Technical
Operational Concept Description (OV-1)
Node Connectivity Description (OV-2)
X YXZ
XY
Y
Systems InterfaceDescription (SV-1)
Activity Model (OV-5)
Information Exchange Matrix
(OV-3)
Activity to System Function (SV-5)
System Functionality Description (SV-4)
Organizational Relationships Chart (OV-4)
Systems Data Exchange Matrix (SV-6)
Operational Activity Sequence and Timing
Description (OV-6 a/b/c)
NODE A
Local Area Net
System 1 System 2
System 3 System 4
System 5
EXTERNALCONNECTION(OUTSIDE THENODES OF INTEREST)
CONNECTIONTO NODE B
CONNECTIONTO NODE B
CONNECTIONTO NODE C
Two-WayCommunicationsLinks
One-WayCommunicationsLink
Systems Communications Description (SV-2)
System - System Matrix (SV-3)
Systems Technology Forecast (SV-9)
Standards Technology Forecast (SV-9)
Technical Architecture Profile (TV-1)
Systems Performance Parameters Matrix (SV-7)
• ----------------------------------------------------------------
• .....• .....• .....
Logical Data Model (OV-7)
Systems Functionality Sequence and Timing
Description (SV-10 a/b/c)
Systems Evolution Description (SV-8)
Physical SchemaSV-11
A B C
T1T2T3
NODESTIME
A B C
T1T2T3
NODESTIME
20
© 2002 The MITRE Corporation. All rights reserved.
Systems Architecture Viewpoints*Systems Architecture Viewpoints*Relationship to DODAFRelationship to DODAF
ISO standard ISO/IEC 10746-1: Reference Model – Open Distributed Processing (RM-ODP)
RM-ODP View Points
Expresses DoD Framework products
DoD Framework UML Products
Enterprise Viewpoint
Business activities supported by the system
IDEF0 Diagrams Use Cases, Use Case Diagrams and related Diagrams
Computational Viewpoint
Logical decomposition of the system as a set of class objects/subsystems
Data Flow Diagrams Classes, Class Diagrams, and related Diagrams
Threads of control, which carry out the computation elements
Statecharts Statechart & Activity Diagrams, Sequence Diagrams
Engineering Viewpoint
Mechanisms to support distribution of functionality
Physical Distribution Component and Deployment Diagrams
Information Viewpoint
Data managed by the system Data Models, Physical Data SchemaRelational Databases
Sequence and Collaboration diagrams, Class Diagrams, OO DBs
Technology Viewpoint
The system and its environment that focuses on the choice of technology in that system.
Matrices Technology standards and properties attached to systems and subsystems
21
© 2002 The MITRE Corporation. All rights reserved.
DoD Architecture Coordination
CouncilC4ISR
Architecture Working Group
C4ISR Architecture Framework Version 1.0
C4ISR Architecture Framework Version 2.0
June 1996
Dec 1997
C4ISR ITFIntegrated
Architectures Panel
Prior Community Experiences
DoD ArchitectureFramework
Version V 1.0
2002
OSDMandate
Feb 1998
Evolution of the Framework & Evolution of the Framework & Timeline Road MapTimeline Road Map
Lead by: Directorate for Architectures and IntegrationOASD(C3I) Architecture
Framework Working Group
2003
22
© 2002 The MITRE Corporation. All rights reserved.
Applicable View Framework Product Framework Product Name
All Views AV-1 Overview and Summary Information
All Views AV-2 Integrated Dictionary
Operational OV-1 High-Level Operational Concept Graphic
Operational OV-2 Operational Node Connectivity Description
Operational OV-3 Operational Information Exchange Matrix
Operational OV-4 Organizational Relationships Chart
Operational OV-5 Operational Activity Model
Operational OV-6a, b, c Operational Activity Sequence and Timing Descriptions
Operational OV-7 Logical Data Model
Systems SV-1 Systems Interface Description
Systems SV-2 Systems Communications Description
Systems SV-3 Systems-Systems Matrix
Systems SV-4 Systems Functionality Description
Systems SV-5 Operational Activity to Systems Function Traceability Matrix
Systems SV-6 Systems Data Exchange Matrix
Systems SV-7 Systems Performance Parameters Matrix
Systems SV-8 Systems Evolution Description
Systems SV-9 Systems Technology Forecast
Systems SV-10a, b, c Systems Functionality Sequence and Timing Descriptions
Systems SV-11 Physical Schema
Technical TV-1 Technical Standards Profile
Technical TV-2 Technical Standards Forecast
DODAF Architecture ProductsDODAF Architecture Products
23
© 2002 The MITRE Corporation. All rights reserved.
(Business Process)Operational Activity Model
AnalyzeMarket
Information Reports
Outputs
(Business Organization)Operational Node
Connectivity Description
HQ
FieldOffice
DPCenter
Phonee-mail
Phonee-mailT3 Line,Satellite
PhoneE-mail
Inputs
Systems Interface Description
System Node
InterfaceSystemSystem
Node
System
System
System Node
System
Technical Standards ProfileOperational Information
Exchange Matrix
Producing Node
Producing Activity
Receiving Node
Receiving Activity
InformationNeedline
Information Exchanged
Also Includes: Triggering EventDescription, ‘Properties’,
Performance, Security
Service Area Service Standard
Applications Software
Data Document XML 1.0Interchange Interchange
(Business Concept)High-Level Operational
Concept Graphic
Importer/Exporter/Broker
SAFE, LEGAL, OPEN TRADE
Carriers Goods
Overview and Summary
Integrated DictionaryDictionary allows capture of Arch
definitions, relationships, attributes, rules
Activity 1 Activity 2 Activity 3
Activity 4 Activity 5
Activity Hierarchy
Some DODAF Architecture ProductsSome DODAF Architecture Products
24
© 2002 The MITRE Corporation. All rights reserved.
NodeA
NodeB
Activity 1 Activity 2
NodeC
Activity 3
Activity 2Activity 3
•Information Description•Name/Identifier•Definition•Media•Size•Units
•Information Exchange Attributes
•Frequency, Timeliness, Throughput•Security•Interoperability Requirements
•Information Source•Information Destination
Information Exchange 1
High-Level Operational
Concept Description
Operational Node Connectivity
Description
Operational Information
Exchange Matrix
High-level graphicaldescription of the operational concept of interest
Operational nodes, activities performed ateach node, node-to-node relationships, and information needlines
Summary of Information exchanged between nodes with attributes, such as security, timeliness
To External
Node
STATEVECTOR
From External
Node
Operational View Captures Critical Mission Operational View Captures Critical Mission Relationships and Information ExchangesRelationships and Information Exchanges
Operational Activity Model
OperationalProcess 1
Outputs
Inputs
OperationalProcess 2
Information
Information
Inputs
Operational activities, information inputs and outputs, conditions
25
© 2002 The MITRE Corporation. All rights reserved.
Data Flow Among System Functions
SystemFunction 1
SystemFunction 2
ExternalSource
Data Flow 1
Data Flow 2
Data Repository
System Nodes,Systems, Links
Systems Interface Description SV-1
Communication Pathways and Networks, Configuration Detail
Station Base
SystemA
SystemB
SystemC
Systems Communications Description SV-2
Systems Functionality Description SV-4Capability Evolution and
Migration
Cap 1Cap 2
Cap 3Cap 4
V 1.0 V2.0
Systems Evolution Description SV-8
Can include systems, H/W & S/W Items, Interfaces (conceptual),System Functions
Can include systems,communications nodes,networks, paths,Links forming path, protocols supported
Includes data sources and sinks, repositories,data flows between system functions
Systems View Captures Systems, Functions Systems View Captures Systems, Functions Performed, Data, and Network LayoutPerformed, Data, and Network Layout
Describes planned systems evolution over time
26
© 2002 The MITRE Corporation. All rights reserved.
Dictionary Content
Reference Model Name
Service Area Name
Service Name
Standard Name
System Name
System Hardware/Software Item Name
Communications System Name
Communications Link Name
Relationships in Dictionary
Orange indicates Technical Architecture ElementsGreen indicates system product Data Element
Technical Architecture Profile (TV-1) Technical Architecture Profile (TV-1)
Reference Model
Service Area
Service
Standard
System
System Hardware/Software Item
Communications System
Communications Link
Systems Data Exchange
System Function
Physical Schema Model
Systems Data Exchange
Physical Schema Model
System Function
27
© 2002 The MITRE Corporation. All rights reserved.
RECOMMENDED USES OF ARCHITECTURE: 1 2 1 2 3 4 5 6 7 1 2 3 4 5 6 7 8 9 10 11 1 2
Planning, Programming, Budgeting Process
PPBS
Capability Based Analysis for IT Investment Decisions
Modernization Planning (including AoAs)
Requirements Generation Process
Determining Mission Needs and Identifying Deficiencies
CONOPS & TTP
Acquisition Process
Program Definition and Risk Reduction
Approval to Begin a New Acquisition Program
Interoperability/Integration of C4ISR Systems
Acquisition Strategy and Source Selection
Cost, Schedule, and Performance Risk Management
Operational and Developmental Test & Evaluation
Systems Engineering (Design & Development)
Operations Planning & Execution
Exercise Planning & Execution
Organizational Design
= Product info is highly applicable = Info is often or partially applicable blank = Info is usually not applicable
Life-Cycle Support & Integrated Digital Environment
BPR / FPI
Operations (Assessment, Planning, Execution, …)
APPLICABLE ARCHITECTURE PRODUCTSAll-
ViewTech View (TV)
Portfolio Management
Technology Insertion / Evolution
System View (SV)Operational View (OV)
Requirements generation
process
Products needed in Requirements
Analysis
Matrix of Products According to UseMatrix of Products According to Use
28
© 2002 The MITRE Corporation. All rights reserved.
Matrix of Products According to UseMatrix of Products According to Use
Purpose – Provide guidance on which architecture products are applicable
to various uses of architecture
Emphasis and expectation– Architecture data underlying the products will be used to support
the DoD core processes– List of uses is not comprehensive but rather a summary of uses
supporting DoD core processes
Increased emphasis on development of integrated architectures and de-emphasis of an architecture product-by-product approach
Increased emphasis on development of integrated architectures and de-emphasis of an architecture product-by-product approach
Requires tighter integration between staffs, operational, and acquisition communities
Requires tighter integration between staffs, operational, and acquisition communities
29
© 2002 The MITRE Corporation. All rights reserved.
DODAF Products and UML RepresentationDODAF Products and UML Representation
Applicable View
Framework Product
Framework Product Name UML Diagram
All Views AV-1Overview and Summary
InformationNone: Produced from domain knowledge, diagram and element
annotations
All Views AV-2 Integrated Dictionary None: Produced from diagram and element annotations
Operational OV-1High-Level Operational
Concept Graphic
None: but may be produced via Use Case Diagrams, one for each use or mission Produced from domain knowledge
Operational OV-2Operational Node
Connectivity Description
Collaboration Diagrams for operational/ organizational nodes
Operational OV-3Operational Information
Exchange Matrix
None: Produced from Collaboration or Sequence Diagram messages (OV-2 collaboration messages)+ additional adornments (e.g., IA attribute)
Operational OV-4Organizational
Relationships ChartClass Diagrams, maps to OV-5 use case actors
Operational OV-5 Operational Activity Model
Use case Diagrams+ Activity Diagrams (to show threads)+ Sequence Diagrams (OV-6c) and StateChart Diagrams (OV-6b)
Operational OV-6a Operational Rules ModelNone: Produced from pre- and post- conditions on OV-5 use cases,
or derived from StateChart Diagrams supporting OV-5 and OV-7 diagram and element adornments
Operational OV-6bOperational State
Transition DescriptionUML Statechart Diagrams
Operational OV-6cOperational Event-Trace
DescriptionUML Sequence Diagrams
Operational OV-7 Logical Data Model Class Diagrams
30
© 2002 The MITRE Corporation. All rights reserved.
DODAF Products and UML RepresentationDODAF Products and UML Representation
Applicable View Framework Product
Framework Product Name UML Diagram
Systems SV-1 Systems Interface Description
Deployment Diagrams+ Component Diagrams for Intra-nodal and Intra-system version of SV-1
Systems SV-2 Systems Communications Description
Deployment Diagrams+ Component Diagrams for Intra-nodal and Intra-system version of SV-2
Systems SV-3 Systems-Systems Matrix None: Produced from SV-1/2 diagram and element adornments
Systems SV-4 Systems Functionality Description
Use Case Diagrams+ Class Diagrams (with operations)+ Collaboration Diagrams (to show data flows or exchanges)
Systems SV-5 Operational Activity to Systems Function Traceability Matrix
None: Produced from OV-5 & SV-4 diagram and element annotations. information may be derived from operational sequence diagrams that are refined into system sequence diagrams
Systems SV-6 Systems Data Exchange Matrix
None: Produced from SV-1, SV-2, & SV-4 diagram and element annotations. information may be derived from system sequence diagrams
31
© 2002 The MITRE Corporation. All rights reserved.
DODAF Products and UML RepresentationDODAF Products and UML Representation
Applicable View Framework Product
Framework Product Name UML Diagram
Systems SV-7 Systems Performance Parameters Matrix
None: Produced from SV-1, SV-2, & SV-4 diagram and element annotations
Systems SV-8 Systems Evolution Description
None: Domain Knowledge, and Framework Systems View Products
Systems SV-9 Systems Technology Forecast
None: Domain knowledge, Technology Knowledge, and Framework Systems View Products
Systems SV-10a Systems Rules Model None: Produced from SV-4, SV-11 diagram and element annotations and constraints, or derived from StateChart Diagrams supporting SV-4
Systems SV-10b Systems State Transition Description
UML Statechart Diagrams
Systems SV-10c Systems Event-Trace Description
UML Sequence Diagrams
Systems SV-11 Physical Schema Class Diagrams
32
© 2002 The MITRE Corporation. All rights reserved.
DODAF Products and UML RepresentationDODAF Products and UML Representation
Applicable View Framework Product
Framework Product Name UML Diagram
Technical TV-1 Technical Standards Profile None: Produced from system elements and applicable Technical standards
Technical TV-2 Technical Standards Forecast
None: Produced from system elements and applicable Technical standards
33
© 2002 The MITRE Corporation. All rights reserved.
US CustomsService
ArchitectureProducts
GSAEnterprise
ArchitectureFramework
TreasuryEnterprise
ArchitectureFramework
Architecture
Framework V1.0
ICArchitecture
Products
FederalEnterprise
ArchitectureFramework
Homeland
Security
Architecture
Products
Other Agencies Building The Same Sets Other Agencies Building The Same Sets Of Comparable Products And Data ElementsOf Comparable Products And Data Elements
DoD ArchitectureFramework
OPERATIONALINFORMATIONELEMENT
DESCRIPTION MEDIA SIZE UNITS
NAME/IDENTIFIERDEFINITION DIGITAL,VOICE,TEXT,IMAGE,ETC.
RANGELIMITS
FEET,LITERS,INCHES,ETC.
OPERATIONALELEMENT &ACTIVITY
OPERATIONALELEMENT &ACTIVITY
IDENTIFIEROF
PRODUCINGOE
PRODUCINGACTIVITY
IDENTIFIEROF
CONSUMINGOE
CONSUMINGACTIVITY
INFORMATIONSOURCE
INFORMATIONSOURCE
INFORMATIONDESTINATION
INFORMATIONDESTINATION
FREQUENCY,TIMELINESS,THROUGHPUT
SECURITYINTEROPER-
ABILITYREQUIREMENTS
INFORMATION EXCHANGE
ATTRIBUTES
INFORMATION EXCHANGE
ATTRIBUTES
INFORMATIONDESCRIPTION
INFORMATIONDESCRIPTION
Operational Information Exchange Matrix
NODE A
System Interface Description
NODE B
NODE C
SYSTEM2
SYSTEM1
EXTERNALCONNECTION
SYSTEM1
COMMS Interfa
ce
COMM
S Inter
face
COMMS InterfaceOne-way SATCOM Interface
SYSTEM2
SYSTEM3
SYSTEM1
SYSTEM4
Technical Architecture ProfileActivity 3NodeA
NodeB
Activity 1 Activity 2
NodeC
Activity 2Activity 3
• Information Description
• Name/Identifier
• Definition• Media
• Size
• Units• Information Exchange
Attributes
• Frequency,
Timeliness,
Throughput• Security
• Interoperability
Requirements
• Information Source
• Information Destination
Information Exchange 1
OperationalNode Connectivity
Description Activity Model
SERVICE AREA SERVICE STANDARDSupport ApplicationsWeb Applications Internet Explorer Version 4.X or better
Netscape Version 3.X or betterData Management Business Data
StandardsData Universal Numbering System (DUNS)
ZIP Code DirectoryCongressional District Identifier
ISO 3166: ISO 3166-1 (1Ocober 1997) and ISO 3166-2 (15 December 1998) (Codesfor the Representation of Names of Countries and Their Subdivisions)
U.S. State Codes and Territory CodesCatalogue for Federal Domestic Assistance ProgramElectronic Grants Data Elements
Data Interchange DocumentInterchange
XML 1.0, W3C Recommendation, 10 February 1998, Rec-xml-19980210 (ExtensibleMarkup Language)
HTML 4.0 Specification, W3C Recommendation revised 24-apr-1998, Rec-html40-19980424 (Hypertext Markup Language)ANSI ASC X12 (Electronic Data Interchange)
Communications World Wide WebServices
IETF RFC-2616 Hypertext Transfer Protocol – HTTP/1.1, June 1999
Electronic Mail IETF Standard 10/RFC-821/RFC-1869/RFC-1870 Simple Mail Transfer Protocol(SMTP) Service Extensions, November 1995
IETF Standard 11/RFC-822/RFC-1049 Standard for the Format of ARPA InternetText Messages, 13 August 1982
IETF RFCs 2045-2049 Multipurpose Internet Mail Extensions (MIME), November1996
34
© 2002 The MITRE Corporation. All rights reserved.
NATO’s
Architecture
Framework
Taiwan’s
Architecture
Australia’s
Architecture
Framework
Sweden’s
Architecture
Framework
UK’s
Architecture
Framework
Other Countries Building Similar Sets Of Other Countries Building Similar Sets Of Comparable Products And Data ElementsComparable Products And Data Elements
US CustomsService
ArchitectureProducts
GSAEnterprise
ArchitectureFramework
TreasuryEnterprise
ArchitectureFramework
Architecture
Framework V1.0
ICArchitecture
Products
FederalEnterprise
ArchitectureFramework
Homeland
Security
Architecture
Products
DoD ArchitectureFramework
OPERATIONALINFORMATIONELEMENT
DESCRIPTION MEDIA SIZE UNITS
NAME/IDENTIFIERDEFINITION DIGITAL,VOICE,TEXT,IMAGE,ETC.
RANGELIMITS
FEET,LITERS,INCHES,ETC.
OPERATIONALELEMENT &ACTIVITY
OPERATIONALELEMENT &ACTIVITY
IDENTIFIEROF
PRODUCINGOE
PRODUCINGACTIVITY
IDENTIFIEROF
CONSUMINGOE
CONSUMINGACTIVITY
INFORMATIONSOURCE
INFORMATIONSOURCE
INFORMATIONDESTINATION
INFORMATIONDESTINATION
FREQUENCY,TIMELINESS,THROUGHPUT
SECURITYINTEROPER-
ABILITYREQUIREMENTS
INFORMATION EXCHANGE
ATTRIBUTES
INFORMATION EXCHANGE
ATTRIBUTES
INFORMATIONDESCRIPTION
INFORMATIONDESCRIPTION
Operational Information Exchange Matrix
NODE A
System Interface Description
NODE B
NODE C
SYSTEM2
SYSTEM1
EXTERNALCONNECTION
SYSTEM1
COMMS Interfa
ce
COMMS In
terfac
e
COMMS InterfaceOne-way SATCOM Interface
SYSTEM2
SYSTEM3
SYSTEM1
SYSTEM4
Technical Architecture ProfileActivity 3NodeA
NodeB
Activity 1 Activity 2
NodeC
Activity 2Activity 3
• Information Description• Name/Identifier
• Definition• Media
• Size
• Units• Information Exchange
Attributes
• Frequency,Timeliness,
Throughput• Security
• Interoperability
Requirements• Information Source
• Information Destination
Information Exchange 1
OperationalNode Connectivity
Description Activity Model
SERVICE AREA SERVICE STANDARDSupport ApplicationsWeb Applications Internet Explorer Version 4.X or better
Netscape Version 3.X or betterData Management Business Data
StandardsData Universal Numbering System (DUNS)
ZIP Code DirectoryCongressional District IdentifierISO 3166: ISO 3166-1 (1Ocober 1997) and ISO 3166-2 (15 December 1998) (Codesfor the Representation of Names of Countries and Their Subdivisions)U.S. State Codes and Territory CodesCatalogue for Federal Domestic Assistance ProgramElectronic Grants Data Elements
Data Interchange DocumentInterchange
XML 1.0, W3C Recommendation, 10 February 1998, Rec-xml-19980210 (ExtensibleMarkup Language)HTML 4.0 Specification, W3C Recommendation revised 24-apr-1998, Rec-html40-19980424 (Hypertext Markup Language)ANSI ASC X12 (Electronic Data Interchange)
Communications World Wide WebServices
IETF RFC-2616 Hypertext Transfer Protocol – HTTP/1.1, June 1999
Electronic Mail IETF Standard 10/RFC-821/RFC-1869/RFC-1870 Simple Mail Transfer Protocol(SMTP) Service Extensions, November 1995IETF Standard 11/RFC-822/RFC-1049 Standard for the Format of ARPA InternetText Messages, 13 August 1982IETF RFCs 2045-2049 Multipurpose Internet Mail Extensions (MIME), November1996
35
© 2002 The MITRE Corporation. All rights reserved.
DODAF V 1.0 - SummaryDODAF V 1.0 - Summary
DoD Issuances provide “teeth” for the architecture process
DoD Architecture Framework– Emphasis on developing and using architectures to support
Department’s major processes Acquisition (5000), Requirements (3170), Budget processes Interoperability
– Model-Driven analysis based on a data-centric approach
36
© 2002 The MITRE Corporation. All rights reserved.
Contact InformationContact Information
Owner of the Architecture Framework:– OASD(C3I)/DoD CIO, – The Directorate for Architectures and Integration
Government Lead: – Truman Parmele 703-607-0502
Support for the Framework:– Fatma Dandashi - Mitre 703-883-7914– Huei-Wan Ang - Mitre 703-883-6701– Patsy McGrady - ACS-Defense 757-229-7887
Available on the Web– http://flrc.mitre.org/dodfw/
37
© 2002 The MITRE Corporation. All rights reserved.
Backup SlidesBackup Slides
38
© 2002 The MITRE Corporation. All rights reserved.
Operational Node Connectivity Description (OV-2)Operational Node Connectivity Description (OV-2)
: Node A
: Node B
: Node C
: External Source
: External Destination
Performs:Activity 1Activity 2
Performs:Activity 3
Performs:Activity 2Activity 3
Nee
dlin
e 2
2: Information Type Y
Needline 1
3: Information Type X
Needline 34: Information Type W
Needline 4
1: Information Type Z
39
© 2002 The MITRE Corporation. All rights reserved.
Operational Information Exchange Matrix (OV-3)Operational Information Exchange Matrix (OV-3)
Needline Identifier
Information Exchange Identifier
Info
rmat
ion
Ele
men
t N
ame
An
d Id
enti
fier
Co
nte
nt
Des
crip
tio
n
Mis
sio
n /
Sce
nar
io U
JTL
o
r M
ET
L
Lan
gu
age
Acc
ura
cy
Tra
nsa
ctio
n T
ype
Tri
gg
erin
g E
ven
t
Inte
rop
erab
ility
Lev
el
Sen
din
g O
p N
od
e N
ame
An
d Id
enti
fier
Sen
din
g O
p A
ctiv
ity
Nam
e A
nd
Iden
tifi
er
Rec
eivi
ng
Op
No
de
Nam
e A
nd
Iden
tifi
er
Rec
eivi
ng
Op
Act
ivit
y N
ame
An
d Id
enti
fier
Nature of Transaction
Information Description Producer Consumer
Needline Identifier
Information
Exchange Identifier
Per
iod
icit
y
Tim
elin
ess
Ava
ilab
ility
Co
nfi
den
tial
ity
Dis
sem
inat
ion
Co
ntr
ol
Info
rmat
ion
Cri
tica
lity
Inte
gri
ty
Acc
ou
nta
bili
ty
Pro
tect
ion
(T
ype
Nam
e,
Du
rati
on
, Dat
e)
Cla
ssif
icat
ion
Cla
ssif
icat
ion
Cav
eat
Performance Attributes
Information Assurance Security
40
© 2002 The MITRE Corporation. All rights reserved.
Organizational Relationships Chart (OV-4)Organizational Relationships Chart (OV-4)
Third Level Organization D
Third Level Organization C
Second Level Organization A
CommandsCommands
Working Group
Coordinates
Second Level Organization B
Top Level Organization
Commands
Coordinates
Commands
41
© 2002 The MITRE Corporation. All rights reserved.
Operational Activity Model (OV-5)Operational Activity Model (OV-5)
Node C
Node A
Node B
Activity 2
External Activity 1
Activity 1
Flow1
Flow 2
External Activity 2
Node D
Activity 3
Flow 3
Flow 4
Conducts
Conducts
ConductsConducts
Conducts
42
© 2002 The MITRE Corporation. All rights reserved.
Operational Activity Model (OV-5)Operational Activity Model (OV-5)
Activity 1.1Flow 1
Activity 1.3
Activity 2.1
Activity 1.2
Flow 2
Activity 2.2
Activity 3
Flow 4
Flow 3
ExternalDestination
Node DNode CNode BNode AExternalSource
43
© 2002 The MITRE Corporation. All rights reserved.
The Operational State Transition Description (OV-6b)The Operational State Transition Description (OV-6b)
State 2State 1 Event[ Guard Condition ] / Action
44
© 2002 The MITRE Corporation. All rights reserved.
The Operational Event-Trace Description (OV-6c)The Operational Event-Trace Description (OV-6c)
: Op Node A : Op Node B : Op Node C
Message 1Time 1
Message 2Time 2
{formula relating Time 1 to Time 2}
Message 3
Time n
Time 3 Message 4
Message 5Time 4
{formula relating Time 3 to Time 4}
Message 6
Message 7
Message 8
45
© 2002 The MITRE Corporation. All rights reserved.
Logical Data Model (OV-7)Logical Data Model (OV-7)
Entity 2 Name
Attribute 1 NameAttribute 2 Name...
Entity 3 Name
Attribute 1 NameAttribute 2 Name...
Entity 1 Name
Attribute 1 NameAttribute 2 Name...
Relationship Name
Entity 4 Name
Attribute 1 NameAttribute 2 Name...
46
© 2002 The MITRE Corporation. All rights reserved.
Systems Interface Description (SV-1 & 2)Systems Interface Description (SV-1 & 2)
Interface 2
Node A
System 1
System 5
Node B
System 1
System 3
Node C
System 1
System 4Node1
External Connection
Sys Func LSys Func M Interface 1
Interface 4
Sys Func N
Sys Func LSys Func M
Sys Func HSys Func ISys Func J
Interface 5
Key Interface 3
47
© 2002 The MITRE Corporation. All rights reserved.
Systems-Systems Matrix (SV-3)Systems-Systems Matrix (SV-3)
Interface characteristics:– Status (e.g., existing, planned,
potential, de-activated)– Purpose (e.g., C2, intelligence,
logistics)– Classification level (e.g., Secret,
TS/SCI)– Means (e.g., Joint Worldwide
Intelligence Communications System, SIPRNet).
SYSTEM1
SYSTEM2
SYSTEM3
SYSTEM4
SYSTEM5
SYSTEM6
SYSTEM7
SYSTEM8
SYSTEM9
SYSTEM10
SYSTEM 1
SYSTEM 2SYSTEM 3SYSTEM 4
SYSTEM 5
SYSTEM 6SYSTEM 7
SYSTEM 10
SYSTEM 8
SYSTEM 9
48
© 2002 The MITRE Corporation. All rights reserved.
Systems Functionality Description (SV-4)Systems Functionality Description (SV-4)Use Case Diagram – 1/3Use Case Diagram – 1/3
User Type A
Systems Use Case 2User Type B
Systems Use Case 1
User Type CSystems Use Case 3
49
© 2002 The MITRE Corporation. All rights reserved.
Systems Functionality Description (SV-4)Systems Functionality Description (SV-4)Class Diagram – 2/3Class Diagram – 2/3
Systems Use Case 1
Package 3Package 2
implemented byimplemented by
Class 1(from Package 2)
Package 1
implemented by
Class 2(from Package 2)
uses
Class 4(from Package 2)
uses
Class 3(from Package 2)
uses
uses
50
© 2002 The MITRE Corporation. All rights reserved.
Systems Functionality Description (SV-4)Systems Functionality Description (SV-4)Collaboration Diagram – 3/3Collaboration Diagram – 3/3
: Class 1
: Class 2
: Class 4
1 : External Source
2 : External Source
1 : External Sink
2 : External Sink
: Class 3 : Data Repository
2:
Data Flow 2
3:
Data Flow 3
4:
Data Flow 4
6:
Data Flow 6
8:
Data Flow 8
7:
Data Flow 7
1:
Data Flow 1
5:
Data Flow 5
9:
Data Flow 9
10: Data Flow 10
51
© 2002 The MITRE Corporation. All rights reserved.
Operational Activity to Systems Function Traceability Operational Activity to Systems Function Traceability Matrix (SV-5)Matrix (SV-5)
1
1.1
1.1.1
1.1.1.1
1.1.1.2
1.1.1.3
1.1.2
1.1.2.1
1.1.2.2
1.1.2.3
1.1.3
1.1.3.1
1.1.3.2
1.1.3.3
1.1.3.4
3.11
3.11
.3
3.12
3.12
.1
3.12
.2
3.12
.3
3.13
3.14
3.14
.1
3.14
.2
3.14
.3
3.14
.4
3.15
3.16
3.17
3.17
.1System Functions
..
..
Operational Activities
X
XX
X
X
X
XX
X
X
X
X
XX
X
OV-5 High Level Operational Capability
SV
-1/2
Sys
tem
s
Ope
ratio
nal C
apab
ility
a
Ope
ratio
nal C
apab
ility
b
Ope
ratio
nal C
apab
ility
c
Ope
ratio
nal C
apab
ility
d
Ope
ratio
nal C
apab
ility
e
Ope
ratio
nal C
apab
ility
f
Ope
ratio
nal C
apab
ility
g
System 1
System 2
System 3
System 4
System 5
System 6
52
© 2002 The MITRE Corporation. All rights reserved.
Systems Data Exchange Matrix (SV-6)Systems Data Exchange Matrix (SV-6)
Interface Identification
Data Exchange
IdentificationData Exchange Identification Nature of Transaction
Systems Interface
Name and Identifier
Systems Data
Exchange Name and Identifier
Content Descripti
on
Format Type
Media Type
Data Standar
d
Units of
Measurement
Accuracy
Transaction Type
Triggering
Event
Interoperability Level
53
© 2002 The MITRE Corporation. All rights reserved.
Systems Data Exchange Matrix (SV-6) Cont’dSystems Data Exchange Matrix (SV-6) Cont’d
Producer Consumer Performance Attributes
Sending System
Name and Identifier
Sending System
Function Name and Identifier
Receiving System Name and Identifier
Receiving System
Function Name and Identifier
Periodicity Timeliness Throughput Size
Information Assurance Security
Access
Control
Availability
Confidentia
lity
Disseminati
on Contr
ol
Criticality
Integrity
Non-Repudiation Produ
cer
Non-Repudiation Consu
mer
Protection
(Type Name, Duratio
n, Date)
Classification
Classification Caveat
Release-
ability
Security Standard
54
© 2002 The MITRE Corporation. All rights reserved.
Performance Parameters Matrix (SV-7)Performance Parameters Matrix (SV-7)
Hardware Element 1
Maintainability
Availability
System Initialization Time
Data Transfer Rate
Program Restart Time
S/W Element 1 / H/W Element 1
Data Capacity (e.g., throughput or # of input types)
Automatic Processing Responses (by input type, # processed/unit time)
Operator Interaction Response Times (by type)
Effectiveness
Availability
Mean Time Between S/W Failures
Organic Training
S/W Element 2 / H/W Element 1
System NameTime0 (Baseline) Time1 Timen (Objective)
Performance Thresholds/Measures
Hardware Element 2
55
© 2002 The MITRE Corporation. All rights reserved.
Systems Evolution Description (SV-8)Systems Evolution Description (SV-8)
LEGACYMAINFRAME
SYSTEM
FEDERATEDDISTRIBUTED
SYSTEM
CLIENT/SERVERPLATFORMS, LAN, &MIDDLEWARE INSTALLED
SEGMENT 1 APPLICATIONS& UNIQUE DATA CONVERTEDTO CLIENT/SERVER
SEGMENT 2 APPLICATIONS& UNIQUE DATA CONVERTEDTO CLIENT/SERVER
SEGMENT 3 APPLICATIONS,& UNIQUE DATA CONVERTEDTO CLIENT/SERVER
COMMON DATA CONVERTEDTO SHARED DATA SERVER
NEW FUNCTION 1 &UNIQUE DATA IMPLEMENTEDON CLIENT SERVER (& INTEGRATED WITH COMMON DATA ON MAINFRAME)
NEW FUNCTION 2 &UNIQUE DATA IMPLEMENTEDON CLIENT SERVER (& INTEGRATED WITH COMMON DATA ON MAINFRAME)
V1.0
V1.1
V1.2
V1.3
V1.4
V2.0
+6 MO. +12 MO. +18 MO. +24 MO. +36 MO. +48 MO. +60 MO.
56
© 2002 The MITRE Corporation. All rights reserved.
Systems Technology Forecast (SV-9)Systems Technology Forecast (SV-9)TRM
TECHNOLOGYCATEGORY
TECHNOLOGY FORECASTS
SHORT TERM(0-6 Months)
MID TERM(6-12 Months)
LONG TERM(12-18 Months)
Application Software
Support Applications Microsoft Office 2000 available (for Windows 2000)
Microsoft Office 2000 stable enough for full scale implementation
Microsoft Office available for LinuxE-mail on wireless PDAs commonplace
Application Platform
Data Management Oracle 9i availableMySQL (Open Source DBMS) available
Operating System Next MS Windows desktop upgrade expectedNext Red Hat Linux major release expected
Next MS Windows server upgrade expected
Physical Environment Intel IA-64 becomes standard processor for desktopsInitial use of quantum computing technologies
External Environment
User Interface Thin screen CRT monitors for PC desktops become price competitive
Thin screen LED monitors become price competitive for desktopsConventional CRT technology monitors for desktops become obsolete
Persistent Storage 5G PCMCIA type 2 card available
Disk storage capacity doubles again
Networks Cable modem service available for most telecommuting staff
Fiber optic connections available for most telecommuting staff
57
© 2002 The MITRE Corporation. All rights reserved.
Systems Functionality Sequence and Timing Systems Functionality Sequence and Timing Descriptions (SV-10)Descriptions (SV-10)
State 2State 1 Event[ Guard Condition ] / Action
: Systems Node A : Systems Node B : Systems Node C
Message 1Time 1
Message 2Time 2
{formula relating Time 1 to Time 2}
Message 3
Time n
Time 3 Message 4
Message 5Time 4
{formula relating Time 3 to Time 4}
Message 6
Message 7
Message 8
58
© 2002 The MITRE Corporation. All rights reserved.
Physical Schema (SV-11)Physical Schema (SV-11)
Entity 2 Name
Attribute 1 NameAttribute 2 Name...
Entity 3 Name
Attribute 1 NameAttribute 2 Name...
Entity 1 Name
Attribute 1 NameAttribute 2 Name...
Relationship Name
Entity 4 Name
Attribute 1 NameAttribute 2 Name...
59
© 2002 The MITRE Corporation. All rights reserved.
DODAF UML Extensions 1/2DODAF UML Extensions 1/2
Currently, the UML specification ties the deployment diagram to choices of hardware and software, and thus forces the use of deployment diagrams as implementation level descriptors of the technology
For the DODAF, nodes in a deployment diagram are associated with systems which are in turn associated with operational activities (use cases)
60
© 2002 The MITRE Corporation. All rights reserved.
DODAF UML Extensions 2/2DODAF UML Extensions 2/2
Need to assign or associate systems which may consist of combinations of hardware and software (stereotyped components), to physical locations (stereotyped deployment nodes), to organizations (actors, roles) responsible for conducting the operational activities, and to operational activities (use cases), without having to develop class diagrams as use case realizations that compose components.
Solution: The above relationships from organizations (actors), to operational activities (use cases), to systems (components), to systems nodes (deployment nodes) should be specified and maintained by the UML and UML modeling tools, without forcing the architect to realize use cases in class diagrams that detail system behavior. The use case model element should have a direct residing-contained relationship with a component. Actors should have a supported-by relationship with a component.
61
© 2002 The MITRE Corporation. All rights reserved.
Volume I: Definitions and GuidelinesVolume I: Definitions and Guidelines
Purpose – Guidance on– Value of architectures – Architecture measures– Framework overview and the six-step process
Audience – Decision makers– Managers
62
© 2002 The MITRE Corporation. All rights reserved.
Volume II: Product DescriptionVolume II: Product Description
Purpose
– Definition, description, and intended use for each Framework product
– Description of product and architecture data element relationships
– Description of corresponding CADM entities and relationships
63
© 2002 The MITRE Corporation. All rights reserved.
Volume II: Product DescriptionVolume II: Product Description
Audience for Volume II:
– For the manager, product definition and purpose section:
Provide a brief overview of architecture products,
Describe level of effort involved in developing each product,
Describe potential uses of architecture products
Allow assessment of products needed to support decisions
64
© 2002 The MITRE Corporation. All rights reserved.
Volume II: Product DescriptionVolume II: Product Description
Audience for Volume II (cont’d)– For the architect and engineering team, a detailed description, and
architecture data element definitions section:
Allow identification of products to be included in the architecture based on architecture’s intended use
Facilitate determination of architecture data needs
Allow identification of sources for the architecture data
Allow analysis and comparison of the data gathered
Facilitate composition of data into architecture products
65
© 2002 The MITRE Corporation. All rights reserved.
Volume II: Product DescriptionVolume II: Product Description
Audience for Volume II (cont’d)
– For the architecture data modelers, tool developers, and engineers, a CADM entities and relationships section:
Facilitate implementation of a CADM compliant architecture Modeling tool
Facilitate implementation of a CADM compliant architecture data repository
66
© 2002 The MITRE Corporation. All rights reserved.
Deskbook: Architecture GuidanceDeskbook: Architecture Guidance
Purpose: provide supplementary guidance on– Developing architectures– Using architectures– Incorporating Security into architectures
Audience – Managers– Architects– Engineers
67
© 2002 The MITRE Corporation. All rights reserved.
Key Changes in Volume IKey Changes in Volume I
Overview of DoD and Federal policies concerning architectures
Information on the value of architectures, architecture measures, and use of architectures to support DoD processes
Introduction to DoD Architecture Repository System (DARS)
68
© 2002 The MITRE Corporation. All rights reserved.
Key Changes in Volume IIKey Changes in Volume II
Data element definitions internally consistent across products
Greater emphasis on architecture data underlying the architecture products
– Data element tables and element attribute definitions– CADM section and corresponding entities
Guidance on developing architecture products using UML
Section on product and data element interrelationships
Technical View is re-titled the Technical Standards View. The acronym remains TV
69
© 2002 The MITRE Corporation. All rights reserved.
Deskbook (New Volume)Deskbook (New Volume)Supplementary Material – Topics Included Supplementary Material – Topics Included
An example architecture using two different approaches (Structured Analysis and Object Orientation)
Some techniques for using architecture information to support DoD processes. These include:
– Navy’s Mission Capability Package analysis approach– Air Force’s Task Force capability-based analysis– OASD(C3I)/J6 Key Interface process for addressing interoperability at interfaces– Key Interface Profiles for addressing interoperability at interfaces– Architecture input to C4I Support Plans
Guidance on using architectures in the Capital Planning Process
Architecture Perspective on Net-centric Operations and Warfare (NCOW)
Guidance on security (information assurance) issues with respect to architecture
The Role of Humans in Architectures
General information on automated tools