1. Vanilson Burégio vaab@cin.ufpe.br
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
February 16, 2019

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
February 16, 2019

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
February 16, 2019

4. Meeting of stakeholders
Presentation – Phase 0
Meeting of stakeholders
Involved people
The evaluation team leader
The customer representatives
Contractor`s architects
Action:contractor 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
February 16, 2019

5. Meeting of stakeholders
Presentation – Phase 0
Meeting of stakeholders
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? …
February 16, 2019

6. Phase 1 Step 1: Present the ATAM Step 2: Present the Business Drivers
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
...
February 16, 2019

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
February 16, 2019

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
February 16, 2019

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 system’s components notified?
...
February 16, 2019

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 -> performance
Passive backup -> backup may have incomplete information
Turning a soldier node into backup/Commander -> 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
February 16, 2019

11. Phase 1 Step 6: Analyze the Architectural Approaches
Independent comunication components approach
Client-server => 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
seconds for soldier to become backup
February 16, 2019

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
February 16, 2019

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)
To determine the criticality of the tradeoff more precisely, we can prototype or estimate the currently antecipated message traffic
The identified tradeoff affected the very viability of the system
February 16, 2019

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 => better undertanding of requirements
New requirements
Switchover (Soldier to commander)
availability
Revealed serious problems in the documentation of the architecture
February 16, 2019

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
February 16, 2019

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
February 16, 2019