Software Architecture in Practice

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

2. Software Architecture in Practice Summary • Chapter 3 – A-7E Avionics System • A Case Study in Utilizing Architectural Structures • Chapter 4 – Understanding Quality Attributes

3. Software architecture in PracticeChapter 3 – A-7E Avionic System About the A-7 Project • Much of the computer science technology being developed in academia and laboratories was NOTbeing 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.

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

5. Software architecture in PracticeChapter 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

6. Software architecture in PracticeChapter 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

7. Software architecture in PracticeChapter 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

8. Software architecture in PracticeChapter 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

9. Software architecture in PracticeChapter 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

10. Software architecture in PracticeChapter 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

11. Software architecture in PracticeChapter 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

12. Software architecture in PracticeChapter 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

13. 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 Software architecture in PracticeChapter 3 – A-7E Avionic System Software Decision Module

14. How the A-7E Module Decomposition Structure Achieves Quality Goals Software architecture in PracticeChapter 3 – A-7E Avionic System

15. Software architecture in PracticeChapter 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

16. How the A-7E Uses Structure Achieves Quality Goals Software architecture in PracticeChapter 3 – A-7E Avionic System

17. Software architecture in PracticeChapter 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

18. How the A-7E Process Structure Achieves Quality Goals Software architecture in PracticeChapter 3 – A-7E Avionic System

19. Software architecture in PracticeChapter 3 – A-7E Avionic System The software never flew !!! Success or Failure ?

20. Software architecture in PracticeChapter 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

21. Software architecture in PracticeChapter 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

22. Software architecture in PracticeChapter 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

23. Software architecture in PracticeChapter 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

24. Software architecture in PracticeChapter 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.

25. Software architecture in PracticeChapter 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

26. Software architecture in PracticeChapter 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

27. Software architecture in PracticeChapter 4 – Understanding Quality Attributes Quality Attributes Scenarios in Practice • General Scenarios • System independent • System specific scenarios • Useful relevant

28. Software architecture in PracticeChapter 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

29. Software architecture in PracticeChapter 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

30. Software architecture in PracticeChapter 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

31. Software architecture in PracticeChapter 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

32. 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 Software architecture in PracticeChapter 4 – Understanding Quality Attributes Security

33. Software architecture in PracticeChapter 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

34. Software architecture in PracticeChapter 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”

35. Software architecture in PracticeChapter 4 – Understanding Quality Attributes Other System Quality Attributes • Attribute Taxonomies • Scalability – Modifying system capacity • Portability – Platform modification • Create your own general scenarios

36. Software architecture in PracticeChapter 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