Software Architecture in Practice RiSE’s Seminars Bass’s book :: Chapters 3, and 4 Eduardo Cruz November 24, 2018

Chapter 3 – A-7E Avionics System Software Architecture in Practice Summary Chapter 3 – A-7E Avionics System A Case Study in Utilizing Architectural Structures Chapter 4 – Understanding Quality Attributes November 24, 2018

Software architecture in Practice Chapter 3 – A-7E Avionic System About the A-7 Project Much of the computer science technology being developed in academia and laboratories was NOT being used by the developers of software for Navy Systems Project started in 1977 Architecture from a redesign project launched by Navy software engineers, using under-utilized technology. November 24, 2018

Architecture Business Cycle Software Architecture in Practice Chapter 3 – A-7E Avionics System Architecture Business Cycle Architect's Influences Architect(s) Stake holders Requirements Developing Organization Technical Environment Architects Experience Architecture Module Structure Uses Structure Process Structure System A-7E Avionics November 24, 2018

Software architecture in Practice Chapter 3 – A-7E Avionic System About the A-7 Project The A-7E software is responsible for reading sensors and updating cockpit displays that help the pilot drop weapons on a target Leave a complete engineering model – documentation, design, code, methodology, principles – that others could emulate, all reported in the open literature November 24, 2018

David Parnas, the man who first wrote about information hiding Software architecture in Practice Chapter 3 – A-7E Avionic System About the A-7 Project David Parnas, the man who first wrote about information hiding Balancing time among inventing new software engineering approaches, learning the avionics domain, writing papers to get the word out and, last but hardly least, producing software November 24, 2018

Software architecture in Practice Chapter 3 – A-7E Avionic System About the A-7 Project Balancing time among inventing new software engineering approaches, learning the avionics domain, writing papers to get the word out and, last but hardly least, producing software Careful attention to module interfaces and module interfaces specifications paid off in essentially eliminating integration as a project phase November 24, 2018

Why A-7E still interesting ? Software architecture in Practice Chapter 3 – A-7E Avionic System Why A-7E still interesting ? Hiding is a viable and prudent design discipline Carefully engineering different structures of na architecture yields payoffs in terms of achievable quality November 24, 2018

A-7E Architecture Architectural Structures Software architecture in Practice Chapter 3 – A-7E Avionic System A-7E Architecture Architectural Structures Decomposition, a structure of modules Uses, a structure of modules Process, a structure of components and connectors November 24, 2018

Decomposition Structure Software architecture in Practice Chapter 3 – A-7E Avionic System Decomposition Structure Unless a program is small enough to be produced by a single programmer, we must think how the work will be divided into units that can be implemented separately and how those modules will interact The goal of the A-7E designers. Achieve modifiability without compromising performance Carefully designed language-independent interfaces area crucial for maintaining portability and achieving interoperability November 24, 2018

Decomposition Structure Software architecture in Practice Chapter 3 – A-7E Avionic System Decomposition Structure Information hiding Abstraction of the sensor Modules - simple enough to be understood fully Change implementation without affecting other modules Test any combination of old and new module versions November 24, 2018

A-7E Module Decomposition Structure Software architecture in Practice Chapter 3 – A-7E Avionic System A-7E Module Decomposition Structure Hardware-Hiding Module Hardware change <=> Software interface Behavior-Hiding Module Requirements changes <=> Procedures changes Software Decision Module Algorithmic efficiency and accuracy November 24, 2018

Software Decision Module Software architecture in Practice Chapter 3 – A-7E Avionic System Software Decision Module Application Data Type Module Data types for avionics applications (ie. Distance, time intervals, angles) Data Banker Module “Middleman” between consumer and producer Filter Behavior Module Digital models of physical filters. Physical Models Module Ballistic weapon strike the ground Software Utility module Mathematical functions, resource monitors System Generation Module Onboard system November 24, 2018

How the A-7E Module Decomposition Structure Achieves Quality Goals Software architecture in Practice Chapter 3 – A-7E Avionic System How the A-7E Module Decomposition Structure Achieves Quality Goals Goal How Achieved Ease of change Information hiding Understand anticipated changes Formal evaluation procedure to take advantage of experience of domain experts Assign work teams so that this interactions were minimized Module structured as a hierarchy November 24, 2018

Software architecture in Practice Chapter 3 – A-7E Avionic System Uses Structures Decomposition structures carries no information about runtime execution of the software (software interaction) The uses (allowed-to-use) structure is conceptually documented with binary matrix System partitioned into layers November 24, 2018

How the A-7E Uses Structure Achieves Quality Goals Software architecture in Practice Chapter 3 – A-7E Avionic System How the A-7E Uses Structure Achieves Quality Goals Goal How Achieved Incrementally Build and test system functions Create “is-allowed-to-use” structure. Limits procedures each can use Design for platform change Restrict number of procedures that use platform directly November 24, 2018

Process Structure Process Software architecture in Practice Chapter 3 – A-7E Avionic System Process Structure Process set of programming steps that are repeated in response to a triggering event or to a timing constraint A-7E - function drivers compute the output of the avionics software Process structure – set of processes in the software Sequences and interactions November 24, 2018

How the A-7E Process Structure Achieves Quality Goals Software architecture in Practice Chapter 3 – A-7E Avionic System How the A-7E Process Structure Achieves Quality Goals Goal How Achieved Map input to output Each process implemented as cycle that samples, inputs, computes and presents outputs Maintain real-time constraints Identify process through process structure and then perform offline scheduling Provide results of time-consuming calculation immediately Perform calculations in background and return most recent value when required November 24, 2018

The software never flew !!! Software architecture in Practice Chapter 3 – A-7E Avionic System The software never flew !!! Success or Failure ? November 24, 2018

Chapter 4 – Understanding Quality Attributes Software architecture in Practice Chapter 4 – Understanding Quality Attributes Chapter 4 – Understanding Quality Attributes Business considerations determine qualities that must be accommodated in a system’s architecture Systems redesigned Not functionality, but difficult to maintain November 24, 2018

Functionality and architecture Software architecture in Practice Chapter 4 – Understanding Quality Attributes Functionality and architecture Functionality and architecture are orthogonal Functionality Ability of the system to do the work for which it was intended Largely independent of structure November 24, 2018

Functionality and Quality Attributes Software architecture in Practice Chapter 4 – Understanding Quality Attributes Functionality and Quality Attributes Must be considered throughout: design, implementation and deployment Usability, Modifiability, Performance Architecture itself is unable to achieve quality if attention is not paid to the details With complex systems, quality attributes can never be achieved in isolation November 24, 2018

System Quality Attributes Software architecture in Practice Chapter 4 – Understanding Quality Attributes System Quality Attributes Architectural problems A system will be modifiable Which quality a particular aspect belongs to Vocabulary Performance community – “Events” arriving at a system Security community – Attacks arriving at a system Availability community – Failures of a systems November 24, 2018

Quality Scenarios Source of stimulus Stimulus Environment Artifact Software architecture in Practice Chapter 4 – Understanding Quality Attributes Quality Scenarios Source of stimulus Some entity: Human, computer Stimulus Condition that need to be considered when it arrives at a system Environment Stimulus occurs within certain conditions Artifact What is stimulated. The whole system or some pieces of it Response Activity undertaken after the arrival of the stimulus Response measure Response should be measurable, so that the requirement can be tested. November 24, 2018

Software architecture in Practice Chapter 4 – Understanding Quality Attributes A collection of concrete scenarios can be used as the quality attribute requirements for a system Concrete Scenarios x Quality Attributes Requirements November 24, 2018

Specification Concrete Scenarios x Quality attribute requirements Software architecture in Practice Chapter 4 – Understanding Quality Attributes Specification Concrete Scenarios x Quality attribute requirements Use case x Functional requirements Not all possible scenarios are created Redundancy is easily corrected Checklist of important quality attributes November 24, 2018

Quality Attributes Scenarios in Practice Software architecture in Practice Chapter 4 – Understanding Quality Attributes Quality Attributes Scenarios in Practice General Scenarios System independent System specific scenarios Useful relevant November 24, 2018

Availability Concerned with system failure and its consequence Software architecture in Practice Chapter 4 – Understanding Quality Attributes Availability Concerned with system failure and its consequence Failure concerns How is detected How frequently may occur Consequences How long is out of operation How to prevent November 24, 2018

Failure and Fault Fault become failure if not corrected Software architecture in Practice Chapter 4 – Understanding Quality Attributes Failure and Fault Fault become failure if not corrected Observable fault, become failure Fail – Time to repair is the time until the failure is no longer observable Scheduled downtimes are not considered November 24, 2018

Modifiability Cost of change What to change When and Who Software architecture in Practice Chapter 4 – Understanding Quality Attributes Modifiability Cost of change What to change Hardware, OS, Performance, number of users When and Who Compile, build, setup, execution Specify, design, implement, test, deploy Time and money, measured November 24, 2018

Performance Timing Arrival Patterns Response to stimulus Software architecture in Practice Chapter 4 – Understanding Quality Attributes Performance Timing Events: Interrupts, messages, user request ... > Number of event sources and arrival patterns > Performance complexity Arrival Patterns Periodic, Stochastic Response to stimulus Latency – Time between arrival and response Deadlines in processing – Engine controller fuel Throughput of the system – Number of transactions per second November 24, 2018

Software architecture in Practice Chapter 4 – Understanding Quality Attributes Security System's ability to resist to unauthorized usage while still providing its service to legitimate users Attack – Attempt to breach security Access data, modify data, deny service Characteristics Nonrepudiation You did (Transaction) Confidentiality Protected data (income tax) Integrity Cannot change data Assurance You are who purport to be (credit card) Availability Free of DOS Auditing Keep track of activities November 24, 2018

Software architecture in Practice Chapter 4 – Understanding Quality Attributes Testability Ease with which software can be made to demonstrate its faults through testing 40% (cost of development) of well engineered systems November 24, 2018

Software architecture in Practice Chapter 4 – Understanding Quality Attributes Usability How easy it is for the user to accomplish a desired task and the kind of support the system provides Learning system features Using system efficiently Minimizing the impact of errors Adapting the system to user needs Increasing confidence and satisfaction “Usability is not architectural” November 24, 2018

Other System Quality Attributes Software architecture in Practice Chapter 4 – Understanding Quality Attributes Other System Quality Attributes Attribute Taxonomies Scalability – Modifying system capacity Portability – Platform modification Create your own general scenarios November 24, 2018

Business Qualities System Qualities x Business Qualities Software architecture in Practice Chapter 4 – Understanding Quality Attributes Business Qualities System Qualities x Business Qualities Cost, schedule, market, marketing Time to market Commercial off-the-shelf (COTS) Cost and benefit Exceed budget Projected lifetime of the system Portability/usability Targeted market Rollout schedule Base functionality w/ features later Integration with legacy system November 24, 2018