Software Architecture in Practice

1. Software Architecture in Practice Len Bass Paul Clements Rick Kazman

2. Software Architecture in Practice • Provides a set of techniques, not a prescriptive method for architectural design. • Based on belief that software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost.

3. SAIP: Evisioning Architecture 1 - The Architecture Business Cycle 2 - What is Software Architecture? 3 - A-7E: A Case Study in Utilizing Architectural Structures

4. SAIP: Creating an Architecture 4 - Understanding quality attributes 5 - Achieving qualities 6 - Air traffic control 7 - Desinging the architecture 8 - Flight simulation 9 - Documenting software architectures 10 - Reconstructing software architectures

5. SAIP: Analysing Architectures 11 - The ATM 12 - The CBAM 13 - The World Wide Web

6. SAIP: Moving from one system to many 14 - Software Product Lines: 15 - CelsiusTech 16 - J2EE/EJB 17 - The Luthor Architecture 18 - Building systems from off-the-shelf components 19 - Software Architecture in the Future

7. Architecture Business Cycle • Architecture is about things not normally thought of as part of the requirements, such as security, modifiability, reliability • Different organizations with the same requirements will produce different architectures

8. What are system stakeholders? • How can their priorities conflict? • How can technical constraints affect the architecture? • Caterpillar • How does the experience of architects and developers affect the architecture? • Innoverse

9. Architecture Business Cycle • Many influences on architect • Architect makes an architecture • System is developed from architecture • System (and architecture) become an influence • What is good about this model? • What is bad?

10. Architecture Business CYCLE • Architecture affects structure of developing organization • Architecture affects goals of developing organization • Architecture affects customer requirements • Building this system develops experience • A few systems change S.E. culture

11. SAIP2: What is Software Architecture? • Document produced early in the project • The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships between them. (page 21)

12. Architectural Structures • Module • Conceptual • Process • Physical • Uses • Calls • Data flow • Control flow • Class

13. “View” is better word than “structure” • Kruchten, P “The 4+1 View Model of Architecture”, IEEE Software 12(6), 1995. • Multiple views are needed to describe architecture, but they are not architecture

14. Johnson: What is software architecture • Software architecture is • what you have to know about a system to be an expert developer • the pattern language shared by the expert developers of the system and how it is applied to this system • high-level model of the system shared by the expert developers

15. What is the difference between? • Architectural pattern • Reference model • Reference architecture • Architecture

16. Why is Software Architecture Important? • Communication among stakeholders • Why do users care about components? • Early design decisions • Transferable abstractions of a system • Can be applied to other systems with similar requirements

17. Qualities of Software Architecture • Maintainability (portable, changeable, understandable, debugable) • Data integrity • Testability • Availability, upgradeability, reliability • Safety, security

18. Why Architecture is Important • Systems are big • Some decisions are hard to change • Most developers weren’t there at the beginning of a project and need the big picture • Qualities like reliability require hard work, they do not happen by accident, and they are properties of the entire system

19. A-7E • Sensors: radar, air probe, inertial measurement set, altimeter, status of bomb racks • Displays: map, heads-up • Does not control aircraft • Does not shoot weapons • Tiny, slow computer

20. Patterns for Time Triggered Embedded Systems • Book by Michael Pont • System has no interrupts; small processes run every so often. • Processes poll I/O devices • In A-7E. • Function drivers read variables and update the display • Other processes read input and update variables

21. Process structure Other process Function driver Model Input Displays

22. Real-time System Design “Patterns for Generating a Layered Architecture”, Barry Rubin, Pattern Languages of Program Design, Addison-Wesley, 1995. Layered architecture of real-time systems with an operator interface

23. A Typical CMA System Operator Interface status, alarms commands Health and Status Tool Control status control feedback Hardware Interface control status feedback Mechanical process

24. A CMA Architecture Layer 5 - Operator interface Layer 4 - Application layer Model system behavior Layer 3 - Modeling layer Model of the mechanical domain (actuator, solenoid, sensor) Layer 2 - Access layer Model of the EE domain (I/O ports) axis of symmetry Layer 1 - Physical layer Physical hardware or simulator Mechanical entities Actuators, solenoid, sensors, etc

25. A-7E Layer 4 - filter behaviors, physical models, function drivers Layer 3 - Data banker, shared services Layer 2 - Device Interfaces axis of symmetry Layer 1 - Physical layer Physical hardware or simulator

26. Important views of A-7E • Processes • Modules • Uses (function calls)

27. How does A-7E handle failure? • Processor can fail • Sensors can fail • It doesn’t handle failure. • Single bad input value gets flushed • Bad sensor? • Multiple sensors require voting, which is not in architecture

28. Summary • Description of A-7E architecture would be better if it described the most important patterns that it uses.