Midterm Review

Review and summary of course material covered by the midterm

In class - February 26

Format

80 minutes Open book - paper only (photocopy or hard copy of book). Coverage: All lecture notes and listed readings up to February 5th inclusive. Four long answer questions, choose one from each: Read code (Java or Python) and interpret diagrams (UML with key) Business cases - "This is company X, these are their business goals" - produce QA and QAS's that demonstrate how the software meets the business goals. You should know: Business rules Architecture drivers Quality attributes and scenarios Views: Module & Component-and-Connector Behaviour Models

---

Table of Contents

^{(in order of appearance)}

Lecture Notes

• Introduction: What is Software Architecture?
• Software Architecture Overview
• Reading Code
• Architecture Stakeholders and Requirements
• Views on Architecture - Modules
• Views on Architecture - Component and Connector
• Architecture and Design
• Documenting Behaviour

Readings

• Textbook Chapter 1
• Textbook Chapter 2
• Textbook Chapter 3
• Textbook Chapter 16
• Textbook Chapter 18
• Textbook Chapter 4
• Textbook Chapter 17

Other Resources

• SEI View Example
• What is Architectural Design?
• SEI Behaviour Tech Report

---

Textbook Chapter 1

^{(notes go here)}

Introduction: What is Software Architecture?

Lecture 1

Every system has an architecture.

"The software architecture of a system is the set of structures needed to reason about the system, which comprise the software elements, relations among them, and properties of both."

Why do we care?

We identify 7 main benefits of a clearly defined software architecture:

1. Divide and conquer the problem - Architecture shows us how to transition up and down the abstraction hierarchy (system purposes down to individual lines of code).
2. Help manage tasks and facilitate collaboration - The architecture helps us figure out who does what.
3. A common language for the system - We establish and reuse styles, patterns, and syntax (like UML)
4. Force us to look beyond "function" and into qualities.
5. Connect business goals to actual software implementation.
6. Avoid high-cost mistakes - by focusing on the "difficult" decisions.
7. The best architectures create options - The "Architectural Runway" consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay. It provides the necessary technical foundation for developing business initiatives and implementing new Features and/or Capabilities.

Textbook Chapter 2

^{(notes go here)}

Software Architecture Overview

Lecture 2

Why We Document

• Software models are useful abstractions for reasoning about the system when the real world system is too complex to be easily reasoned with.

• Implications of documentation:

  • Systems have many (many) structures. We need to filter the ones we really care about.
  • No single structure is the architecture.
  • Every system has an architecture, which may be more or less visible in the documentation.
  • We can only define whether an architecture (i.e. set of structures) is "good" or not by understanding how well it meets its quality requirements and ultimate business goals.

Software Models

There are three main modes for creating a software model:

1. Diagram as Sketch - Sketches are usually only useful in a specific context. Often, sketches alone will not contain enough information/context to accurately and meaningfully portray a system or some aspect thereof. Sketches are typically short-term communication tools.

2. Diagram as Blueprint - Blueprints are built specifically to be handed off to downstream users (analogous with civil engineer handing off building blueprints to general contractor). Blueprints are meant to be precise and unambiguous.

3. Diagram as Executable - This is most common where there are tight constraints on safety or security, such as in automotive software. In this mode we may use a code-generation tool like Simulink to draw block diagrams which a built-in compiler can then translate into C code.

Textbook Chapter 3

^{(notes go here)}

Reading Code

Lecture 3

^{(notes go here)}

Textbook Chapter 16

^{(notes go here)}

Architecture Stakeholders and Requirements

Lecture 4

Software in itself is not important, and cannot be measured for quality/satisfiability without recognizing who the system is for - these are the stakeholders.

The following table will serve as our template for identifying and describing stakeholders:

Role	Concerns	Instances
Acquirers	Oversee the procurement of the system or product
Assessors	Oversee the system’s conformance to standards and legal regulation
Communicators	Explain the system to other stakeholders via its documentation and training materials
Developers	Construct and deploy the system from specifications (or lead the teams that do this)
Maintainers	Manage the evolution of the system once it is operational
Production Engineers	Design, deploy, and manage the hardware and software environments in which the system will be built, tested, and run
Suppliers	Build and/or supply the hardware, software, or infrastructure on which the system will run
Support Staff	Provide support to users for the product or system when it is running
System	Administrators Run the system once it has been deployed
Testers	Test the system to ensure that it is suitable for use
Users	Define the system’s functionality and ultimately make use of it

Textbook Chapter 18

^{(notes go here)}

Views on Architecture - Modules

Lecture 5

^{(notes go here)}

Textbook Chapter 4

^{(notes go here)}

SEI View Example

^{(notes go here)}

Views on Architecture - Component and Connector

Lecture 6

^{(notes go here)}

Textbook Chapter 17

^{(notes go here)}

What is Architectural Design?

^{(notes go here)}

Architecture and Design

Lecture 7

^{(notes go here)}

SEI Behaviour Tech Report

^{(notes go here)}

Documenting Behaviour

Lecture 8

^{(notes go here)}

Notes:

Business rules

^{(notes go here)}

Architecture drivers

^{(notes go here)}

Quality attributes and scenarios

^{(notes go here)}

Views: Module & Component-and-Connector

^{(notes go here)}

Behaviour Models

^{(notes go here)}