The Battlefield Control System The First Case Study
The Battlefield Control System – The First Case Study in Applying the ATAM Chapter 4 of: Clements, Paul et al. , Evaluating Software Architectures 24 September 2021 Vanilson Burégio vaab@cin. ufpe. br
Summary n n n Introduction Evaluation Preparation (Phase 0) Evaluation Phase 1 ¡ n Evaluation Phase 2 ¡ n Steps 1 to 6 Step 7 and 9 Results of the BCS Evaluation 9/24/2021 2
Introduction n The chapter shows a brief example of using ATAM in a real evaluation n Concentrates on the major activities of Phase 1 and Phase 2 n Some of the details have been changed for pedagogical reasons n 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 9/24/2021 3
Presentation – Phase 0 Meeting of stakeholders n Involved people ¡ ¡ ¡ n n 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 9/24/2021 4
Presentation – Phase 0 Meeting of stakeholders n Samples of Requested additional architecture information §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? §… n 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) 9/24/2021 5
Phase 1 n Step 1: Present the ATAM ¡ ¡ n 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 n n Information on the sorts of battlefield missions Specific requirements ¡ ¡ ¡ Support to command soldier nodes Needs to interface with numerous other systems Requirements respect to set of hardware and software Frequent changes in message format. . . 9/24/2021 6
Phase 1 n Step 3: Present the Architecture ¡ ¡ ¡ n 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 n n ¡ Client-server Backup commander Domain-specific design patterns. . . Each approach was probed for risks, sensitivities, and tradeoffs via our attribute-specific questions 9/24/2021 7
Phase 1 n Step 5: Generate the Quality Attribute Utility Tree ¡ Considered quality attributes n n n ¡ Performance Modifiability Availability Initial prioritized attributes The quality atributes were elicited, specified down to the level of scenarios, annotated with stimuli and responses, and prioritized 9/24/2021 8
Phase 1 n 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 n n How is the failure of a component detected? How is the failure os a communication channel detected? How are the system’s components notified? . . . 9/24/2021 9
Phase 1 n Step 6: Analyze the Architectural Approaches ¡ Backup commander Approach n n n Attribute: availability Server is a potencial single point of failure Three considerations for changing the BCS to improve availability: ¡ ¡ ¡ n n 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 9/24/2021 10
Phase 1 n Step 6: Analyze the Architectural Approaches ¡ Independent comunication components approach n n Client-server => server as a bottleneck Attribute: Performance Analized senario: Turning a soldier node into a backup Performance analisis of needed activities: ¡ ¡ ¡ n Downloading mission plans Update to environmental database Acquiring issued orders Acquiring soldier location and status Acquiring inventories 216. 05 seconds for soldier to become backup Measurable attribute: Qp = h(n, m, CO) ¡ ¡ Qp - Performance n – # Acknowledging backup m - # Passive backup CO – communication overhead 9/24/2021 11
Phase 2 n Step 7: Brainstorm and prioritize Scenarios ¡ The elicited scenarios were prioritized via a voting process involving all stakeholders n ¡ n 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 9/24/2021 12
Phase 2 n 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 n n Qa = g(n, m) Qp = h(n, m, CO) 9/24/2021 13
Results of the BCS Evaluation Revealed serious problems in the documentation of the architecture n Documentation ¡ ¡ n 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 n n Switchover (Soldier to commander) availability 9/24/2021 14
Results of the BCS Evaluation n 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) n controlled by parameters n and m 9/24/2021 15
Conclusion n The example did not show ¡ ¡ ¡ n 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 9/24/2021 16
- Slides: 16