Joint AAR Architecture Development

1
Joint AAR Architecture Development

• Evolution of the OneSAF AAR Architecture

2
Evolving the Architecture

• Baseline Architecture
• Receive Stakeholder Requirements
• Allocate Stakeholder Requirements
• Develop Use Case Scenarios
• Identify Extensions
• Define Extensions

3
(No Transcript)
4
Block C Architecture Baseline

• No Quality Attributes
• PLRS specified
• SRS specified
• Use Case Scenarios identified, not well defined.
• Components and Interfaces defined

5
Joint After Action Review

• OneSAF AAR Extended

6
JAAR Concept of Development Integration
7
Receive Stakeholder Requirements

• Capture Stakeholder Quality Attributes
• If the sponsor of a system cannot tell you what
  any of the quality goals are for the system, then
  any architecture will do.
• Quality attributes are used in context to
  architectural evaluation techniques
• Allocate Requirements
• Allocate to Components
• Identify Specification Level

8
JAAR System Requirements
9
Adopt Use Case Scenarios

• Use Case Scenarios represent the threads by which
  to evaluate an architecture in context to its
  quality attributes
• Use Case Scenarios provide first impressions for
  any architecture
• Not the same as software (UML) use cases
• These threads represent methods of evaluating the
  architecture in context to a stakeholders
  quality attributes
• Joint AAR Operational Activities

10
Operational Activities (DODAF)
11
Allocate Requirements

• Allocate to Components
• For each component ask what this stakeholders
  requirement means in the component's context
• Identify Specification Level
• Identify the specification level of each
  requirement for example
• 0 No Allocation
• 1 Specified
• 2 Designed
• 3 Implementation (Partial)
• 4 Complete

12
Identify Extensions

• Analyze Requirements
• Identify how implementation falls short of
  providing for quality attributes in context to
  the requirements
• Develop Integration Alternatives
• Ensure each alternative is distinguishable from
  the others
• Analyze Alternatives
• Weigh alternatives by quality attributes and
  other common criteria
• Select Alternatives
• This process is representative of a trade-off or
  decision analysis and resolution study

13
Operational Integration View
14
System Integration View
15
Technology Integration View
16
Integration Architecture

• Based on DODAF
• Operational Level
• This is how the AAR systems is delivered and
  integrated with Joint training sites
• Systems Level
• This is how Service tool sets are integrated
  seamlessly with JAAR Core Components
• Technology Level
• This is how AAR components interoperate based on
  technology standards

17
DODAF Alignment
18
Integration Approach

• Evaluate Rate tool sets in context to
  Operational Activities
• Select tool sets are a central context of
  integration by Rating.
• Integration by loose coupling through a Service
  Oriented Architecture
• Agents, and Agent Frameworks

19
AAR Planning Activity (OV-5)
20
OC Tools (SV-2)

• Data Collection Manager plans and manages Data
  Collection
• Documents and templates provided to observer
  controllers.
• Observer Controllers and annotate observations in
  context Joint tasks, and measures.
• Real-time feedback is passed on for data
  collection.
• Observations are published

OC Tool (PDA) Federation
PDA Controller
4
Data Fusion
3
2
5
1
Documents Templates
Relational Database
Technical Control
21
Gateways
Exercise Middleware Layer
Data Collector Middleware Layer
Gateway Application
JAAR Data Collector
JAAR Database
C4I
C4I
DIS
DIS
Relational Database
Data Collector
Gateway
HLA
HLA
TENA
TENA

• Publication

1 Translation
3 Collection
4 Publication
1 Translates from an exercise protocol to a JAAR
data collection protocol
2 Publishes the translated protocol through
middleware to a JAAR Data Collector.
3 Collects the data through a middleware
component.
4 Publishes the translated data through ODBC to
other JAAR Components.
22
Technical Standards (TV-1)
23
Questions
ISBN 020170482X
ISBN 0201703726
ISBN 0201703327
24
Questions