CompSci331: Lecture 12 Introduction to Software Architecture

• This lecture introduces Software Architecture
• The lecture includes a Case Study: BusTracker

Agenda Items:

• Case study
• References
• Software Architecture Overview
• Reading: The Architecture of Open Source Applications, Volume II. Scalable Web Architecture and Distributed Systems by Kate Matsudaira

Case Study: BusTracker

• A series of videos going through the various aspects of software architecture development
• The example is similar to the Auckland Transport Live Departures system

References

• Resources include "Software Architecture in Practice" by Len Bass, Paul Clements, and Rick Kazman, with the 3rd edition available online
• Another resource is "The architecture of open source applications" by Amy Brown and Greg Wilson
• Other books include “Essential Software Architecture” by Ian Gorton and “Software architecture: perspectives on an emerging discipline” by Mary Shaw, David Garlan

Motivation

• Given a brief description of a system for providing a Concert Booking Web Service, describe a "good enough" Software Architecture for it
• Relevant questions include: What is a software architecture? How to describe a software architecture?
• How do you know it is good enough? (Answer: It has the required quality attributes)
• What are qualitas attributes? How do you demonstrate that a given software architecture has specific quality attributes?

Second Motivation

• Build a system for managing pay-as-you-park solutions, a competitor to ParkMate
• System provides real-time tracking of parking space availability to a central control center for monitoring and user information
• Questions include: Should it be a web service or based on containers? Will a web service be fast enough and how to ensure reliability and security?
• How to maximize a team of 20 developers' productivity?
• Design a system maximizing the use of small servers due to power and air conditioning limitations
• How synchronous should the communication be?

Definitions of Software Architecture

• Many definitions exist, including over 100 documented at http://www.sei.cmu.edu/architecture/definitions.html
• Software Architecture constitutes the structure of the components of a program/system
• Software Architecture Includes their interrelationships, and principles and guidelines governing their design and evolution over time
• It is the set of significant decisions about the organization of a software system
• Software Architecture comprises the selection of structural elements and interfaces, their behavior and collaborations, and the architectural style
• The software architecture involves the structure or structures of a system
• The software architecture includes software elements, their externally visible properties and the relationships among them

Common Phrases

• "large scale components”
• "system level abstraction”
• "components and interaction between components"
• "system level analysis
• "load-bearing walls"

Why Software Architecture

• Systems are getting bigger and more complicated, needing "standard" solutions and reuse for common problem types
• Architecture allows communicating and understanding, organizing construction and evolution, and enabling analysis and management
• Large scale decisions are more important than data structures and algorithms from a total system cost viewpoint

Software Lifecycle Integration

• Software Architecture lies between Specification and Detailed Design

Topics

• Understand how to classify architectures, their styles, and how to describe them
• Analyze a given architecture, determining what needs to be known to reason effectively
• The goal is to create a new architecture ensuring what issues need to be considered
• Determine how architectures should be documented and what's important to show

What Software Architecture Is Not

• Not System (or Computer) Architecture
• Software Architecture is not always about functionality, but about qualities
• Isn't just a box-and-line drawing alone

What is Software Architecture?

• The software architecture of a program or computing system comprises the structure or structures of the system
• It comprises software elements, the externally visible properties of those elements, and the relationships among them

Describing Architectures

• Architectures cannot be fully understood by looking at one picture
• Software Architectures for a reasonable size system will consist of multiple structures each providing different information to answer questions
• To describe a structure, provide one or more views describing relevant software elements and their relationships

Good and Bad Architectures

• Architectures are not inherently "good" or "bad", relevance comes meeting quality requirements or having required attributes
• Quality is not absolute, it is measured relative to considered important criteria

Relevant Quality Attributes

• Examples of attributes include:
  • Extensibility
  • Performance
  • Security
  • Understandability
  • Readability
  • Comprehensibility
  • Modifiability
  • Maintainability
  • Portability
  • Buildability
  • Scaleability
  • Availability
  • Reliability

Properties of Software

• Consider importance or getting the system built quickly (buildability)
• Evaluate making changes to it cost effectively, whether to fix faults (modifiability or maintainability)
• Make modifications to add new functionality cost effectively (extensibility)
• Determine the ability to move systems onto different hardware and/or operating systems (portability)
• Ensure new developers can quickly understand the software (understandability, readability, comprehensibility)

Client-Server Architecture

• The "seminal architectural model which remains the most widely adopted"
• One consideration is: What makes something “Client-Server"?
• It is important to ask when you should and should not use Client-Server
• Examples in use with this paradigm are:
  • Git
  • Canvas
  • Google
  • Amazon
  • Excel
  • SPSS (statistics)

Client-Server Attributes

• Extensibility: Only the server needs to change
• Performance: Add more servers
• Security: Communications channel is a weak link
• Understandability, Readability, Comprehensibility: separation is possible (UI only) separately from server (no UI), added protocol complexity
• Modifiability: Change client and server independently
• Maintainability: Faults in client won't affect server
• Portability: Change client and server hardware independently
• Buildability: More work to do
• Scaleability: Add more clients
• Availability: System can be unavailable even if server (client) is working
• Reliability; more things to fail

Layers

• A layer encapsulates everything below it

Layer Attributes

• Performance: More layers can mean slower performance
• Buildability/Modifiability/Understandability: Only need to deal with one layer at a time
• Portability: Only the lower layer(s) need to change

Replication and its forms

• Under which circumstances should different forms be used?

Attributes of Replication

• Availability, Performance (Latency): Broadcast style increases by reducing effect of server failures without waiting for the slowest server, but broadcast in general does not scale
• Performance (throughput): Processing a client request through a single server allows more requests to be processed simultaneously, and increases throughput
• Scaleability: Can add as many servers as are needed, sometimes at the cost of performance

Describing the Code

• Decompose along functional lines into modules and each module gets deployed in different places

Specifying Quality

• Software architectures depend on quality attribute requirements

Key Points

• Software architecture is the "large-scale" view of a system's design, showing the “important” design decisions
• Architecture choice depends on the desired qualities of the system, not the functionality itself
• Understanding architecture concepts informs what questions to ask