1 / 34

Software Architecture in Practice

Software Architecture in Practice. Tactics. Context. Introduction. Tactics : Architectural techniques to achieve required quality attributes i.e. control the response measure in a positive direction The following presentation is selected picks from the book

solana
Download Presentation

Software Architecture in Practice

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Architecturein Practice Tactics

  2. Context Henrik Bærbak Christensen

  3. Introduction • Tactics: Architectural techniques to achieve required quality attributes • i.e. control the response measure in a positive direction • The following presentation is selectedpicks from the book • Representing my key interests or central tactics • Testability, modifiability, availability • … and representing areas of my missing expertise • Security  Henrik Bærbak Christensen

  4. Availability • Availability: Property of software that it is ready to carry out its task when you need it to be. • Lots of metrics… • MTBF: Mean Time Between Failures (Airbus 380) • MTTR: Mean Time To Repair (NetFlix) • MTBF / (MTBF+MTTR) Henrik Bærbak Christensen

  5. Event Sourcing Henrik Bærbak Christensen

  6. Tactics Categories • Detect Faults • Our system needs to know that something has failed! • Examples • Heartbeat • MongoDB’s replica set emit heart beats to fellow instances • Exception Detection • MongoDB’s Java driver will throw an exception in case a write request cannot be fulfilled Henrik Bærbak Christensen

  7. Tactics Categories • Recover from Faults / Prep and repair • Once detected, how do we get back on track? • Examples • Active Redundancy: millisecond take over • Passive Redundancy: second-minute take over • Spare: hour-days take over • Exception handling • Degradation • Run with cached data (off-line) Henrik Bærbak Christensen

  8. Tactics Categories • Recover from Faults / Reintroduction • How to get failed components working again • Examples: • State resynchronization • MongoDB slave 1 needed two days to get back Henrik Bærbak Christensen

  9. Tactics Categories • Prevent Faults • Can we avoid it in the first place • Examples: • Transactions: ACID in RDB • Increase competence set: Read Nygard’s book and employ the techniques  - Safe failure modes Henrik Bærbak Christensen

  10. Evolving World • Tactics are of course not a static set, and Bass et al. do not present a comprehensive catalogue. • One missing tactic is ‘event sourcing’ • (Fowler, 2005) (https://martinfowler.com/eaaDev/EventSourcing.html) • Definition: Event Sourcing ensures that all changes to application state are stored as a sequence of events. • I.e. only use CRud of the database CRUD operations. Henrik Bærbak Christensen

  11. Summary • Availability: Property of software that it is ready to carry out its task when you need it to be. • There are lots of tactics • Some are simple, directly in programming language • Like exceptions • Some are wildly complex • Passive redundancy • Look for the complex ones in external libraries Henrik Bærbak Christensen

  12. Interoperability • Interoperability: Concerned with the degree to which two or more systems can usefully exchange meaningful information via interfaces in a particular context Henrik Bærbak Christensen

  13. Tactics • Locate: e.g. DNS lookup • Manage interface: • Orchestrate ~ Mediator pattern; Tailor ~ Decorator Henrik Bærbak Christensen

  14. Hm • Bit thin, isn’t it? • Extensible interface • Add version number in message • JSON and XML are pretty flexible, you can always add stuff, and older clients may then ignore additional attributes • Postel’s law / Robustness principle • Be conservative in what you do, be liberal in what you accept from others Henrik Bærbak Christensen

  15. Modifiability • Modifiability: Concerned with the ease with which the system supports change Henrik Bærbak Christensen

  16. Tactics Henrik Bærbak Christensen

  17. Tactics • Cohesion and Coupling: Old friends… • Defer binding = Dependency injection • Constructor injection, Abstract Factory, DI frameworks • Program to an Interface • Favor object composition Henrik Bærbak Christensen

  18. Performance • Performance: Concerned with ability to meet timing requirements Henrik Bærbak Christensen

  19. Tactics Henrik Bærbak Christensen

  20. Tactics • Either lower demand or increase muscles  • Make the wagon lighter or add more horses in front… • Demand examples • Increase resource efficiency: better algorithms • Reduce overhead: avoid too much network traffic • Manage resources • Increase: Vertical scale (up) • Multiple copies data: cache • Multiple copies comp: • Horizontal scale (out) Henrik Bærbak Christensen

  21. Security • Security: Concerned with ability to protect data and information from unauthorized access while still providing access to people/systems that are authorized But Master i IT has quite a few fagpakker on the topic! One of the major flaws in myknowledge base  Henrik Bærbak Christensen

  22. Tactics Henrik Bærbak Christensen

  23. • Change default settings • How many of you have changed the default admin password on your Wireless Router at home ? Henrik Bærbak Christensen

  24. Testability • Testability: Concerned with the ease with which the software can be made to demonstrate its faults I run a complete ‘fagpakke fag’ on this single quality Henrik Bærbak Christensen

  25. Tactics Henrik Bærbak Christensen

  26. Tactics • Specialized interfaces • Tests often deliberately breaks encapsulation! • Allow it, but only through dedicated test interfaces! • Sandboxing • Program to an interface and allow test doubles to be injected instead of DBs, external hardware, etc. • Use virtual machines • Staging environments • Docker-compose  • Limit complexity • Program to interface, favorobject composition  Henrik Bærbak Christensen

  27. Evolving World • Also here I find a tactic missing (or a category) ‘Ease of demonstratefaults’ equalsspeed! • Test Process • Automation • RegressionSpeed • Monitoring Henrik Bærbak Christensen

  28. Tactic • Test Process Tactics • Automation: Ensure that tests are executed automatically/programmatically, not by hand • xUnit frameworks • Continuous Integration servers on dedicated branches • Regression Speed: Ensure your automated tests can be executed fast. Unit tests in seconds, integration/service tests in minutes, system/end-to-end tests in hours. • Service Doubles Henrik Bærbak Christensen

  29. Tactic • Test Process Tactics • Monitoring: Monitor production systems and report anomalies • Monitor log messages • Simian army to produce failure conditions in prod. ”My suggestions” are of course not part of exam curriculum! Henrik Bærbak Christensen

  30. Usability • Usability: Concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides Henrik Bærbak Christensen

  31. Tactics Henrik Bærbak Christensen

  32. Tactics • Undo and cancel ! Record macros Henrik Bærbak Christensen

  33. Summary • Some are high level architectural decisions • Passive redundancy, … • Some are low level programming decisions with strong architectural influence • Reduce module size, introduce concurrency, … Definition: Tactic is a design decision that influences the achievement of a quality attribute response Henrik Bærbak Christensen

  34. My Architecture Perception • Some say • ”Architecture is the ability to draw 7 boxes with lines between them” • I say • ”Architecture is any decision that influence QAs” • Which leads to the corollary • Architectural work span the entire spectrum of decisions from the highest level all the way down to programming statement level! • Klaus Marius Hansen, Architect at Microsoft • ”I spent quite a lot of time programming architectural prototypes…” Henrik Bærbak Christensen

More Related