COMPSCI331 Software Architecture Introduction

• COMPSCI331: Large-Scale Software Development for Week 7 Lecture 1 is an introduction to Software Architecture, by Ewan Tempero, School of Computer Science.

Agenda

• Several topics will be discussed including a case study, references, motivation, what is achitecture as well as looking at quality

Case Study: BusTracker

• BusTracker is a case study consisting of series of videos (about 5) that go through aspects of software architecture development.
• BusTracker is similar to the Auckland Transport Live Departures system.

References

• Good references for Software Architecture include:
• Software Architecture in Practice by Len Bass, Paul Clements, Rick Kazman - 1st (1998), 2nd (2003), and 3rd (2013) editions
• The Architecture of Open Source Applications by Amy Brown & Greg Wilson (editors), Volumes I & II http://aosabook.org
• Essential Software Architecture by Ian Gorton (2006)
• Software Architecture: Perspectives on an Emerging Discipline by Mary Shaw, David Garlan (1996)

Motivation

• When given a brief description of a system providing a Concert Booking Web Service, describe a "good enough" Software Architecture for it.
• In that scenario, you would need to consider:
• What is a software architecture?
• How do we describe a software architecture?
• How do we know it is good enough? (Answer: It has the required quality attributes)
• What are qualitas attributes?
• How do we demontrate that a given software architecture has specific quality attributes?

Motivation 2

• You are about to start building a system for managing pay-as-you-park solutions (e.g. a competitor to ParkMate).
• Requirements for this system include real-time tracking of available and occupied parking spaces to a central control centre and provide available parking to users, as well as payment support.
• In this case, you would need to consider:
• Should it be a web service, or only a web service, or a web service based on containers?
• Will a web service be fast enough (and how fast does it need to be?)
• How do we ensure reliability and security?
• How do we maximise the productivity of a team of 20 developers?
• How do we design the system to make best use of the avalaible small servers?
• How synchronous should the communication be?

What is Architecture

• There are many definitions of software architecture
• The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time. (Garlan and Perry, Guest editorial, IEEE Transactions on Software Engineering, April 1995)
• An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization—these elements and their interfaces, their collaborations, and their composition (Booch, Rumbaugh, and Jacobson, The UML Modeling Language User Guide, 1999).
• The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. (Bass, Clements, Kazman Software Architecture in Practice
• Some other phrases used include
• 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.
• There is a need for "standard" solutions to common problem types to enable reuse.
• Software architecture helps towards understanding, communication, construction, evolution, analysis, and management.
• Large scale decisions are more important (from a total system cost viewpoint) than data structures and algorithms.
• In the Software Lifecycle:
• Requirements
• Specification
• Architecture
• Detailed Design
• Implementation
• Topics include:
• Classification: How do we organise architectures? What kinds (or "styles") or architectures are there? How do we describe an architecture?
• Analysis: Given an architecture, how do we reason about it? What do we need to know about it to reason effectively?
• Develop: How do we decide on an architecture for a system? How do we create a new architecture? What issues to we have to keep in mind?
• Documentation: How should architectures be described? What are the important things to show?

What Software Architecture is Not

• Software architecture is not System (or Computer) Architecture.
• Software Architecture is not about functionality.
• Software Architecture is not a box-and-line drawing.
• The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
• This includes:
• Multiple structures
• Software elements and relationships
• Externally visible properties
• An architecture rarely can be fully understood by just looking at one picture.
• The architecture for a system of a reasonable size will typically consist of multiple structures.
• Different structures provide different information about the architecture, and so help answer different kinds of questions.
• Different structures may have different kinds of software elements and/or relationships.
• To describe a structure, we must provide one or more views of it.
• A view must describe the relevant software elements and their relationships.
• An architecture is not inherently "good" or "bad".
• The only criteria of relevance is "meets quality requirements” or “has the required quality attributes".
• Quality is not absolute, but relative to what criteria are considered important.

Quality Attributes

• Quality Attributes relevant to Software Architecture include:
• Extensibility
• Performance
• Security
• Understandability
• Readability
• Comprehensibility
• Modifiability
• Maintainability
• Portability
• Buildability
• Adaptability
• Scaleability
• Availability
• Reliability
• What properties of software are more important?
• Getting the system built quickly (buildability)
• Making changes to it cost effectively, whether to fix faults or to cope with changing conditions (modifiability or maintainability)
• Making changes to it to add new functionality cost effectively (extensibility)
• Be able to move systems onto different hardware and/or operating systems (portability)
• Having developers new to the project be able to understand it quickly enough to be able to be useful (understandability, readability, comprehensibility)

Examples of quality attributes

• Client-Server is a seminal architectural model which is the most widely adopted
• Need to consider what makes something “Client-Server", When should we use Client-Server and when should we not use Client-Server.
• For example, is Client-Server necessary and sufficient for Git, Canvas, Google, Amazon, Excel, SPSS (statistics)?
• Client-Server Relevant Quality Attributes include:
• Extensibility
• Performance
• Security
• Understandability, Readability, Comprehensibility
• Modifiability
• Maintainability
• Portability
• Buildability
• Scaleability
• Availability
• Reliability
• Layers:
• A layer encapsulates everything below it
• Quality Attributes relevant to Layers include:
• Performance
• Buildability/Modifiability/Understandability
• Portability
• Replication needs to take into account what circumstances should different forms be used?
• Quality Attributes relevant to Replication include:
• Availability, Performance (Latency)
• Performance (throughput)
• Scaleability

"Code"

• Decompose along functional lines into modules
• Different modules get deployed in different places
• Systems have subsystems
• Subsystems have architecture

Specifying Quality

• Software architecture depends on quality attribute requirements.
• We need to specify these requirements so that we can determine if a given software architecture meets them.

Key points

• The software architecture of a system is the "large-scale" view of its design, showing the “important” design decisions.
• The choice of architecture for a system depends on the quality attributes the system must meet, not the functionality.
• Understanding software architecture concepts helps inform what questions to ask.