The Battlefield Control System

1
The Battlefield Control System The First Case
Study in Applying the ATAM
Chapter 4 of Clements, Paul et al., Evaluating
Software Architectures

• Vanilson Burégio
• vaab_at_cin.ufpe.br

2
Summary

• Introduction
• Evaluation Preparation (Phase 0)
• Evaluation Phase 1
• Steps 1 to 6
• Evaluation Phase 2
• Step 7 and 9
• Results of the BCS Evaluation

3
Introduction

• The chapter shows a brief example of using ATAM
  in a real evaluation
• Concentrates on the major activities of Phase 1
  and Phase 2
• Some of the details have been changed for
  pedagogical reasons
• The Battlefield Control System (BCS)
• System to be used by arm battlalions to control
  the movement, strategy, and operations of troops
  in real time in the battlefield
• Build by a contractor
• Based upon government-furnished requirements

4
Meeting of stakeholders
Presentation Phase 0

• Involved people
• The evaluation team leader
• The customer representatives
• Contractors architects
• Actioncontractor presented the architecture, and
  the contractor and customer described the initial
  quality attribute requirements
• Result Additional architectural documentation
  was requested
• Documentation had high-level data flows and
  divisions of functionality
• There was no discussion of architectural
  approaches

5
Meeting of stakeholders
Presentation Phase 0

• Samples of Requested additional architecture
  information
• Between phase 0 and 1 the contractor answered
  many of these questions and produced more
  complete documentation (the basis for the
  remainder of the evaluation)

• What is the structure of the message-handling
  software, that is, how is the functionality
  allocated to modules, functions, APIs, layers,
  and so on?
• What is the process and/or task view of the
  system, mapping of these process/tasks to
  hardware and the communication mechanisms between
  them?
• What functional dependencies exist among the
  software components?
• What data is kept in the database? How big is it,
  how much does change, and who reads/writes it?

6
Phase 1

• Step 1 Present the ATAM
• Meeting to present the ATAM to a large group of
  assembled stakeholders
• Time to ask any question about the method, its
  outcomes, and its goals
• Step 2 Present the Business Drivers
• The customer presented the business driver
• Information on the sorts of battlefield missions
• Specific requirements
• Support to command and soldier nodes
• Needs to interface with numerous other systems
• Requirements respect to set of hardware and
  software
• Frequent changes in message format
• ...

7
Phase 1

• Step 3 Present the Architecture
• Contractor presented the architecture
• Contractor and customer described their initial
  quality attribute requirements and set of
  scenarios
• The architectural documentation covered several
  views of the system
• Step 4 Identify the Architectural Approaches
• The architects presented the adopted
  architectural approaches
• Client-server
• Backup commander
• Domain-specific design patterns
• ...
• Each approach was probed for risks,
  sensitivities, and tradeoffs via our
  attribute-specific questions

8
Phase 1

• Step 5 Generate the Quality Attribute Utility
  Tree
• Considered quality attributes
• Performance
• Modifiability
• Availability
• The quality atributes were elicited, specified
  down to the level of scenarios, annotated with
  stimuli and responses, and prioritized

Initial prioritized attributes
9
Phase 1

• Step 6 Analyze the Architectural Approaches
• Set of questions derived from quality attributes
  characterizations to probe the architectural
  approaches for risks, sensitivity points, and
  tradeoffs
• Examples of applied questions
• How is the failure of a component detected?
• How is the failure os a communication channel
  detected?
• How are the systems components notified?
• ...

10
Phase 1

• Step 6 Analyze the Architectural Approaches
• Backup commander Approach
• Attribute availability
• Server is a potencial single point of failure
• Three considerations for changing the BCS to
  improve availability
• Acknowledging backup -gt performance
• Passive backup -gt backup may have incomplete
  information
• Turning a soldier node into backup/Commander -gt
  backup need to download any missed data
• Each of these options has implications for both
  performance and availability
• Measurable attribute Qa g(n, m)
• Qa - Availability
• n Acknowledging backup
• m - Passive backup

11
Phase 1

• Step 6 Analyze the Architectural Approaches
• Independent comunication components approach
• Client-server gt server as a bottleneck
• Attribute Performance
• Analized senario Turning a soldier node into a
  backup
• Performance analisis of needed activities
• Downloading mission plans
• Update to environmental database
• Acquiring issued orders
• Acquiring soldier location and status
• Acquiring inventories
• Measurable attribute Qp h(n, m, CO)
• Qp - Performance
• n Acknowledging backup
• m - Passive backup
• CO communication overhead

216.05 seconds for soldier to become backup
12
Phase 2

• Step 7 Brainstorm and prioritize Scenarios
• The elicited scenarios were prioritized via a
  voting process involving all stakeholders
• Each stakeholder was given 12 votes
• Example of scenarios A new message format is
  added to the system
• Step 8 Analyze the Architectural Approaches
• Testing phase
• High-priority scenarios was apped onto the
  appropriate architectural approaches
• No news and significant risks or tradeoffs were
  found

13
Phase 2

• Step 9 Preset the results
• Identified three sensitivities in the BCS
• The most of them were affected by the same
  architecural decision the amount of message
  traffic over the shared communication channel
• Qa g(n, m)
• Qp h(n, m, CO)

14
Results of the BCS Evaluation

• Documentation
• higher-quality architectural documentation was
  produced
• It was identified by management as a major
  success of using the ATAM (even before presented
  any findings)
• Requirements
• Increased stakeholders comunication gt better
  undertanding of requirements
• New requirements
• Switchover (Soldier to commander)
• availability

Revealed serious problems in the documentation of
the architecture
15
Results of the BCS Evaluation

• Sensitivities and Tradeoffs
• most important tradeoff communications load on
  the system
• Performamce and availability of the system were
  highly sensitive to the latency of the
  communication channel (limited and shared)
• controlled by parameters n and m

16
Conclusion

• The example did not show
• actions the contractor took
• which alternatives the organization chose
• what lessons they learned
• The main point was to show that the process of
  performing an ATAM evaluation on the BCS raised
  the stakeholders awareness of critical risk,
  sensitivity, and tradeoff issues