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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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