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 1 17 - 313 Software Engineering

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. 2 17 - 313 Software Engineering

Learning Goals

• Understand the abstraction level of architectural reasoning
• Approach software architecture with quality attributes in mind
• Distinguish software architecture from (object- oriented) software design
• Use notation and views to describe the architecture suitable to the purpose
• Document architectures clearly, without ambiguity
• Understand the benefits and challenges of traceability. 4 17 - 313 Software Engineering

About You

I am familiar with how to design distributed, high-availability, or high-performance systems No Theory Only Yes 5 17 - 313 Software Engineering

Quality Requirements, now what?

• "should be highly available"
• "should answer quickly, accuracy is less relevant"
• "needs to be extensible"
• "should efficiently use hardware resources" 7 17 - 313 Software Engineering

Software Architecture

8 17 - 313 Software Engineering

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 13 17 - 313 Software Engineering

Caching

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

Programming Model

• Ruby model: Concurrency at process level; request queued to be handled by one process
• Twitter response aggregated from several services – additive response times
• "As we started to decompose the system into services, each team took slightly different approaches. For example, the failure semantics from clients to services didn’t interact well: we had no consistent back-pressure mechanism for servers to signal back to clients and we experienced “thundering herds” from clients aggressively retrying latent services."
• Goal: Single and uniform way of thinking about concurrency
  • Implemented in a library for RPC (Finagle), connection pooling, failover strategies and load balancing

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