Antifragile Software Design
Download as PPTX, PDF•13 likes•10,780 views
The document presents concepts from Nassim Taleb's book 'Antifragile' as applied to software design, highlighting the importance of creating systems that thrive on change and volatility. It introduces a 'barbell strategy' in software architecture, advocating for a separation of robust abstractions and fragile implementation details to enhance software adaptability. The discussion further emphasizes componentization, low coupling, and high cohesion principles to create antifragile systems, enabling shared components that allow for benefitting from improvements across multiple applications.
Antifragile Software Design
- 3. Antifragile This presentation is inspired on the book “Antifragile” by Nassim Taleb.
- 4. The Triad: Antifragility, Robustness, and Fragility Fragile things are exposed to volatility, so that volatility is prejudicial to them. Robust things are immune to volatility, so that volatility does not affect them. Antifragile things enjoy volatility, so that volatility is beneficial to them.
- 5. The Triad Over Time Fragile things: Break, erode or deteriorate. Robust things: Stay the same. Antifragile things: Evolve, improve, get better.
- 6. Antifragility vs. Resilience “Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better.”
- 7. Nonpredictive Decision Making “Sensitivity to harm from volatility is tractable, more so than forecasting the event that would cause the harm.” Aligned with Agile principle: “Responding to change over following a plan.”
- 8. Volatility in Software Design In the case of software systems, volatility appears in the form of changes over time. Changes are unavoidable, as expressed in the Lehman laws of software evolution: “Continuing Change — A software system must be continually adapted or it becomes progressively less satisfactory.”
- 9. Changes in Software Design Functional changes: ◦ Required to implement new requirements, or to implement modifications in the requirements. ◦ Have an impact on the system’s behavior and functionality. Non-functional changes: ◦ Required to improve the quality of the design. ◦ Are normally the result of Refactoring and focus on the reduction of Technical Debt. ◦ Should not affect the system’s behavior or functionality.
- 10. Barbell Strategy “Barbell Strategy: A dual strategy, a combination of two extremes, one safe and one speculative, deemed more robust than a ‘monomodal’ strategy.”
- 11. Example of Barbell Strategy “An investment strategy in which half the portfolio is made up of long-term bonds and the other half of very short- term bonds.”
- 12. Barbell Strategy in Software What is the software equivalent of a Barbell Strategy? The answer is: Abstraction. Software systems should have a structure and organization based on different levels of abstraction. The duality of the Barbell Strategy is expressed as the separation between high-level abstract elements and concrete implementation details.
- 13. Abstract and Concrete Elements Abstract elements: Are robust, and should not be easily affected by changes. Concrete implementation details: Are fragile, directly affected by changes. Software systems should be built in such a way that the volatility (changes): ◦ Does not affect its structure and organization, preserving the main, high- level abstractions. ◦ Requires modifications only on the low-
- 14. Applications of the Barbell Strategy Information Hiding Encapsulation Open/Closed Principle TDD Inheritance Hierarchies Frameworks
- 15. Information Hiding Information Hiding was defined by David Parnas as a criterion to decompose a system into modules: “Every module … is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings.”
- 16. Encapsulation The mechanism of Encapsulation in Object Oriented Programming (OOP) is a direct application of Information Hiding. The interface of a class is separated from its implementation, and thus the implementation may be changed without affecting the clients of the class. Thanks to encapsulation, the clients of a class become less fragile to changes in its implementation details.
- 17. Open/Closed Principle The Open-Closed Principle (OCP) was defined by Bertrand Meyer as: “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” The implementation of the OCP requires the definition of an abstraction, so that each possible extension is a specialization of this abstraction.
- 19. TDD: Test-Driven Development The fundamental idea of TDD is to write the tests before writing the code. TDD focuses on the early separation between abstractions and concrete implementation details. Requires the definition of abstract interfaces and behavior for the classes being tested. Allows the code to be easily refactored, because the unit tests would catch any mistake. The unit tests are less fragile to volatility (changes) because they are based on abstractions.
- 20. Inheritance Hierarchies In OOP, an inheritance hierarchy organizes classes according to a generalization-specialization rationale. Classes near the root of the hierarchy are more abstract than the classes on the leaves of the inheritance tree. The abstract classes should be less fragile than the concrete classes, meaning that they should be less subject to impact caused by volatility, such as changes in the requirements or changes in the implementation details.
- 21. Frameworks Frameworks provide reusable code that is not application-specific, defining abstractions and the relationships among them. The software developer extends the framework, deriving concrete subclasses, and writing the implementation details to satisfy the requirements of a specific application. These implementation details are fragile, but the framework is not, and may be reused with no changes on many
- 22. Robust vs. Fragile Robust Fragile Dependency on interface Dependency on implementation details Client of encapsulated class Client of class with public members Class that may be extended without modifications Class that needs to be modified to be extended Unit Tests Implementation of the classes being tested Abstract Class Concrete Class Generic Framework Application-specific extension of the
- 23. Conclusions so far Software systems are subject to volatility in the form of changing requirements. Concrete implementation details are fragile and directly affected by these changes A Barbell Strategy defines concrete details as the specialization of higher- level abstractions. Proper abstractions should be robust, surviving the impact of changes. Details change over time, but the system structure and organization may be preserved because it is based on abstractions.
- 24. Antifragile Whole, Fragile Parts “The antifragility of the whole often depends on the fragility of the parts.”
- 25. Componentization It is common knowledge that systems should be divided into components. The reaction to a change in the environment should only affect a few components, and not the entire system. Thus, component-based systems are more robust than monolithic systems.
- 26. Antifragility through Componentization To be Antifragile, a system must be able to benefit from changes in the environment. Antifragility may be achieved when several systems share the same components. When a specific component is improved, all systems using this component can benefit from this improvement.
- 27. Example: Rechargeable Batteries All users of traditional AA batteries can benefit from improved technology of rechargeable ones.
- 28. Coupling and Cohesion Principles to guide the decomposition of large software systems into modules: Coupling: The degree of dependency between two modules. We always want low coupling. Cohesion: The measure of how strongly-related is the set of functions performed by a module. We always want high cohesion.
- 29. Applications of Componentization DLLs ORBs SOA Microservices Software Product Lines
- 30. DLL: Dynamic Link Library “DLLs provide a mechanism for shared code and data, allowing a developer of shared code/data to upgrade functionality without requiring applications to be re-linked or re- compiled.”
- 31. ORB: Object Request Broker “An ORB acts as a broker between a client request for a service from a distributed object or component and the completion of that request.”
- 33. SOA Principles 1. Standardized Service Contracts 2. Service Loose Coupling 3. Service Abstraction 4. Service Reusability 5. Service Autonomy 6. Service Statelessness 7. Service Discoverability 8. Service Composability 9. Service Interoperability
- 34. Service Reusability “Services contain and express agnostic logic and can be positioned as reusable enterprise resources.” “Logic is divided into services with the intent of maximizing reuse.” Thus services should not be part of a single system, they should be reused in multiple systems.
- 35. Microservices
- 36. Microservices Practices (I) 1. Separated Build: ◦ Each Microservice is built independently and has its own version. 2. Independent Deployment: ◦ Each Microservice may be deployed without affecting the others. 3. Separated Data Stores: ◦ Microservices should not share data stores. 4. Independence of Platform: ◦ Microservices should be deployed in containers.
- 37. Microservices Practices (II) 5. Individual Technology Choice: ◦ Each Microservice may be implemented using a different technology. 6. Confinement of Failure: ◦ If a failure occurs in a particular Microservice it should not propagate to the other ones. 7. Independent Scalability: ◦ It should be possible to scale each Microservice independently of the others.
- 38. Systems, Services and Antifragility At any point in time it is possible to deploy an enhanced version of one of the services without affecting the other ones. If there are several systems based on shared services, each time one of these services is improved all the systems will be able to immediately benefit from the improvement. While each system is robust, the collection of systems is Antifragile, because they benefit from the same changes at no added cost.
- 39. Software Product Lines In a Software Product Line (SPL), a series of software products are based on the same components and differ only on their configuration. In the case of SPLs there may be several coexisting versions for each component. Each time a new component version is created, all the products using previous versions may benefit through simple configuration updates.
- 40. Antifragile vs. Fragile Antifragile Fragile Several programs linking to the same DLLs A specific version of a Dynamic Link Library Several Client objects calling the same Servant object The implementation details of a specific Servant object Several Systems accessing the same Services The implementation details of a specific Service Several Applications using shared Microservices The implementation details of a specific Microservice Several Products based A specific version of a
- 41. Conclusions A simple strategy for Antifragility is: Build component-based systems with shared components. When one of the shared components is improved all the systems will be able to benefit from this improvement at no additional cost.