Introduction to Software Architecture and Documentation, Lecture notes of Software Engineering

Download Introduction to Software Architecture and Documentation and more Lecture notes Software Engineering in PDF only on Docsity! Foundations of Software Engineering Lecture 8: Introduction to Software Architecture and Documentation Michael Hilton 17-313 Software Engineering1 Interview Josh Gardner! BS in Computer Science from University of Buffalo Developer at SPAWAR 4 years Server Lead at Mobiquity Inc. 5 years Mobiquity is a software services company, meaning we sell our skills in building software (mobile apps, web apps and now Alexa skills) and building cloud infrastructure to other companies. That covers the whole range of activites, visual design, project management, and dragging what they actually want out of them ('gathering requirements'), and then building the system. My personal role has become a combination of actually writing nodejs code, and managing a pack of fellow server devs on one of our large health care projects. Previously I was a rank and file developer for a few consumer services type apps, and then was a full stack lead on a smaller Healthcare app (Novartis Heart Partner). Software services is interesting in that you have to frequently deal with different customers and different types of work (both technically and managerially) so I have sometimes a fairly different view of the business than folks who work in a more product company type setup, where the vision can often extend years in advance. 17-313 Software Engineering2 About You I am familiar with how to design distributed, high-availability, or high-performance systems No Theory Only Yes 17-313 Software Engineering5 17-313 Software Engineering6 Requirements Miracle / genius developers Implementation Architecture Quality Requirements, now what? • "should be highly available" • "should answer quickly, accuracy is less relevant" • "needs to be extensible" • "should efficiently use hardware resources" 17-313 Software Engineering7 Why Architecture? [BCK03] • Represents earliest design decisions. • Aids in communication with stakeholders – Shows them
how at a level they can understand, raising questions about whether it meets their needs • Defines constraints on implementation – Design decisions form
load-bearing walls of application • Dictates organizational structure – Teams work on different components • Inhibits or enables quality attributes – Similar to design patterns • Supports predicting cost, quality, and schedule – Typically by predicting information for each component • Aids in software evolution – Reason about cost, design, and effect of changes • Aids in prototyping – Can implement architectural skeleton early Beyond functional correctness • Quality matters, eg., – Performance – Availability –Modifiability, portability – Scalability – Security – Testability – Usability – Cost to build, cost to operate 17-313 Software Engineering13 Case Study: Architecture and Quality at Twitter 17-313 Software Engineering14 Inspecting the State of Engineering • Running one of the world’s largest Ruby on Rails installations • 200 engineers • Monolithic: managing raw database, memcache, rendering the site, and presenting the public APIs in one codebase • Increasingly difficult to understand system; organizationally challenging to manage and parallelize engineering teams • Reached the limit of throughput on our storage systems (MySQL); read and write hot spots throughout our databases • Throwing machines at the problem; low throughput per machine (CPU + RAM limit, network not saturated) • Optimization corner: trading off code readability vs performance Caching Api Web Memcached institute for | iS) SOFTWARE RESEARCH Twitter's Quality Requirements/Redesign goals?? • Improve median latency; lower outliers • Reduce number of machines 10x • Isolate failures • "We wanted cleaner boundaries with “related” logic being in one place" – encapsulation and modularity at the systems level (rather than at the class, module, or package level) • Quicker release of new features – "run small and empowered engineering teams that could make local decisions and ship user-facing changes, independent of other teams" performance modifiability maintainability reliability Independent Systems • " In our monolithic world, we either needed experts who understood the entire codebase or clear owners at the module or class level. Sadly, the codebase was getting too large to have global experts and, in practice, having clear owners at the module or class level wasn’t working. Our codebase was becoming harder to maintain, and teams constantly spent time going on “archeology digs” to understand certain functionality. Or we’d organize “whale hunting expeditions” to try to understand large scale failures that occurred." • From monolithic system to multiple services – Agree on RPC interfaces, develop system internals independently – Self-contained teams Storage • Single-master MySQL database bottleneck despite more modular code • Temporal clustering – Short-term solution – Skewed load balance – One machine + replications every 3 weeks • Move to distributed database (Glizzard on MySQL) with "roughly sortable" ids • Stability over features – using older MySQL version Search Query Blender Workflow 1 Proxy Layer Workflow 3 Real-time | | Top Tweet Geo Index Tweet DB User DB Index Index institute for | S SOFTWARE RESEARCH On Saturday, August 3 in Japan, people watched an airing of Castle in the Sky, and at one moment they took to Twitter so much that we hit a one- second peak of 143,199 Tweets per second. Key Insights: Twitter Case Study • Architectural decisions affect entire systems, not only individual modules • Abstract, different abstractions for different scenarios • Reason about quality attributes early • Make architectural decisions explicit • Question: Did the original architect make poor decisions? Further Readings • Bass, Clements, and Kazman. Software Architecture in Practice. Addison- Wesley, 2003. • Boehm and Turner. Balancing Agility and Discipline: A Guide for the Perplexed, 2003. • Clements, Bachmann, Bass, Garlan, Ivers, Little, Merson, Nord, Stafford. Documenting Software Architectures: Views and Beyond, 2010. • Fairbanks. Just Enough Software Architecture. Marshall & Brainerd, 2010. • Jansen and Bosch. Software Architecture as a Set of Architectural Design Decisions, WICSA 2005. • Lattanze. Architecting Software Intensive Systems: a Practitioner’s Guide, 2009. • Sommerville. Software Engineering. Edition 7/8, Chapters 11-13 • Taylor, Medvidovic, and Dashofy. Software Architecture: Foundations, Theory, and Practice. Wiley, 2009.