EECS 581 Exam 2

What are the 5 steps/activities in software development?

Vision/planning, requirements, design, implementation, testing, maintenance

What do we design first after establishing the requirements?

Software architecture

Requirements engineering

A set of activities that identify, document, and communicate the purpose of a new software app

What is the scope of requirements engineering?

Defines the functionalities, services, and constraints under which the software application will be developed

What must requirements be?

Systematic, comprehensive, expressed in multiple notations

Systematic

Defined through a repeatable, disciplined process

Comprehensive

Capturing all functionalities, services, and constraints

Expressed in multiple notations

Natural language, models, diagrams, and formal specifications

What is a requirement?

• An expression of desired behavior

• Software requirements are capabilities that the system must deliver, but not how it should be designed

Where do requirements come from?

• Stakeholders’ needs

• Domain model

• Requirement templates (suggested requirements)

• Current situation model

Where does AI fit in requirements engineering?

AI helps compress the grunt work (drafting, summarizing, checking consistency) so more time goes to talking with stakeholders

Issues/risks of using AI

• Invented facts: AI may fill in details no stakeholder ever stated

• Privacy: Never paste real patient data or interview transcripts into public AI tools

• Accountability: AI drafts, the analyst decides

What are the four RE activities?

• Domain engineering

• Requirements elicitation

• Requirements modeling and documentation

• Requirements validation

Functional requirements

Say what the system does

• The system shall alert the care team when a patient’s vital signs breach a threshold

Non-functional requirements

Say how well it must do it

• An alert reaches the care team within 10 seconds of a threshold breach

Why does architecture matter?

• Code alone does not achieve non-functional requirements, structure does.

• Non-functional requirements become the quality attributes that drive architectural decisions

Architectural design

The system’s overall structure

Interface design

The contracts between components

Detailed (procedural) design

The inside of each component

• Algorithms, data structures, control flow

• Guided by design concepts: abstraction, information hiding, cohesion, low coupling, and design patterns

Why do we start with architecture design?

Every later decision depends on it, and it is the most expensive to change.

What is a software system’s architecture?

The set of principal design decisions made about a system to be developed

What is a software architecture represented in terms of?

• Software components

• Software connectors

• Configuration (topology)

• A rationale for the decomposition

Software component

A self-contained unit of functionality

What are the key characteristics of a software component?

• Encapsulates functionality and data

• Defined interface for access

• Modular and reusable

• Hides implementation details

Benefits of a software component

• Composability

• Reusability

• Evolvability

Software connector

Enables communication between components

Architectural configuration (topology)

• How components and connectors are arranged

  • Physical/Layout arrangement of components

  • Communication pathways through connectors

  • System’s overall structure and organization

What are the five creative acts of design?

Framing, imagining, choosing, building, reflecting

What is the great divide between humans and AI in programming?

• AI generates options while humans judge and choose

Experience and judgement

An architect’s past work is a library of solutions and lessons learned

Learning from the ecosystem

Study successful systems instead of reinventing the wheel

Architectural styles

Reusable templates for common system structures

Main program and subprogram style

• An organized hierarchy of function calls

• Main routine orchestrates the overall flow and delegates work to smaller, specialized subprograms

• Emphasis on modularity

Layered style

A stack of layers; each calls only the one below

Repository

Independent components share a central data store

Pipe and filter

Data streams one way through independent filters

Microservices

Small, independent services talking over a network

Characteristics of main program and subprograms style

• Control flow starts from main program

• Tree-like structure with clear parent-child relationships

• Single thread of execution

Pros of main program and subprograms

• Simple to understand and debug

• Clear program structure

Cons of main program and subprograms

• Can lead to tight coupling

• Difficult to modify or extend

Product line

A family of related systems that share a common set of reusable assets

Design patterns

Reusable solutions to common problems

Why use design patterns?

• Accelerate development

• Improve design quality

• Common vocabulary for teams

• Capture expert knowledge

What are the two classifications for design patterns?

• Purpose

  • Creational, structural, behavioral

• Scope

  • Class or object

Where do architectures come from?

1. Experience and judgement

2. Similar systems

3. Architectural styles

4. Reference architecture

5. Design patterns

6. Design principles

Adapter pattern

A structural design pattern that allows incompatible interfaces to work together by using an adapter to translate calls, without modifying the original classes.

What are the consequences of an adapter pattern?

• Reuse existing code

• No changes to original classes

• Adds complexity

Observer design pattern

A behavioral design pattern where one object (subject) automatically notifies its subscribed objects (observers) when its state changes, allowing them to react.

Consequences of using the observer design pattern

• Loose coupling between subjects and observers

• Dynamic relationships

• Unexpected updates if not managed

How are architectural styles and design patterns used together?

1. Design the architecture: Choose an architectural style, identify major components, and define how they communicate.

2. Design inside the components: Apply design patterns to solve specific problems involving classes and objects.

Abstraction

Focus on essential features while hiding unnecessary details

Modularity

Divide a system into separate units or modules

Separation of concersns

Separate distinct responsibilities, such as UI, business logic, and data storage

High cohesion

Keep closely related responsibilities together within a module

Low coupling

Minimize dependencies between modules

Small interfaces

Expose only the operations other modules need

Information hiding

Hide internal design decisions likely to change behind a stable interface

Reusability

The ability to use software components again in other contexts

Design concepts

Abstraction, modularity, separation of concerns, high cohesion, low coupling, small interfaces, information hiding, reusability

Architecture Description Languages (ADLs)

Formal languages for describing software architectures.

• Formats: Textual, graphical, mathematical, or hybrid.

• Benefits: Precise documentation, clear stakeholder communication, automated analysis, and checking correctness and completeness.

How does software architecture help achieve quality attributes?

Architectural choices support non-functional requirements, such as performance, modifiability, security, scalability, availability, and interoperability.

What are the six key quality attributes?

• Performance: How quickly the system responds and how much work it handles.

• Modifiability: How easily it can be changed.

• Security: How it protects data and controls access.

• Scalability: How well it handles growing demand.

• Availability: How consistently it is operational and accessible.

• Interoperability: How well it works with other systems.

What are architectural tactics?

Reusable design techniques applied within an architecture to achieve specific quality attributes.

What is a layered architecture?

• The system is organized as a stack of layers

  • Each layer has one kind of responsibility

  • Each layer provides services to the layer above it

  • Each layer uses services only of the layer below it

What are the classic three layers of a layered architecture?

Presentation, business logic, data access

Presentation layer

Handles user input and displays results. Does not enforce business rules or directly store data

• What did the user ask?

Business logic layer

Applies domain rules and determines which actions are allowed. Independent of screen and storage details

• Is it allowed?

Data access layer

Stores and retrieves data. Does not decide business rules or handle user interaction

• Where is it kept?

What is the dependency rule for layered architecture?

• Dependencies point downward only

  • A layer may call the layer directly below it

  • A lower layer never calls, or even includes a layer above

  • No circular dependencies

Do results travel back up as return values or calls in layered dependency?

Return values

Strict layering

call only the layer immediately below

Relaxed layering

May call any lower layer; faster, but more coupling

Pros of layered architecture

• Separation of concerns: each layer can be understood on its own

• Changes stay local: replace the UI or the storage without touching the rules

• Testability: Test a layer by replacing the one below with a stub

• Teamwork: different teams can own different layers

Cons of layered architecture

• Overhead: every request passes through every layer

• Pass-through code: some functions only forward a call down

• Cross-cutting changes: adding a new field touches every layer

What is a reference architecture?

A standardized, reusable blueprint for a particular domain that defines components and their interactions, provides a proven structure, and establishes common vocabulary.

What is the purpose of the OSI model as a reference architecture?

To guide network protocol design, support interoperability, and simplify complex networking systems by organizing responsibilities into seven layers.

The repository style

• A central data store holds the system’s shared state

• Independent components read and write that store

  • They never call each other and do not even know the others exist

Layered style vs repository style

Layered style: components call each other

Repository style: components share data instead

A repository

A central data store that all clients access, either to read, write, or both

Passive repository

Components ask: they query or poll the data when they need it

Active repository

The repository notifies: interested components are called when data changes

Pros of the repository style

• Independent components: add or remove one without touching the others

• One source of truth: every component sees the same data

• Data in one place: backup, recovery, and security are handled centrally

Cons of repository style

• Single point of failure: if the repository fails, everything stops

• Possible bottleneck: every read and write goes through it

• Format changes ripple: change the shared data, and every reader may change

• Concurrent writers need coordination (locks, transactions)

Does the repository style make changing the components or shared data easy?

Adding a component is easy while changing the shared data is not

The pipe and filter style

• Data flows one way through a chain of processing steps

• Filters do the work while pipes connect the output of one filter to the input of the next

• No shared state: filters communicate only through the data

Filters

• Each reads a stream of data, transforms it, and writes a stream

• Each knows only the format of its input and output

• No filter knows which filters come before or after it

Pipes

A mechanism that connects the output of one process to the input of the next

Source

Where the data comes from (a file, a sensor, a network)

Sink

Where the result ends up (a file, a screen)

Streaming

All filters run at once; data flows as soon as it is ready

Batch sequential

Each step finishes before the next one starts

What are the two ways to run a pipeline?

Streaming and batch sequential

Pros of the pipe and filter style

• Reuse: general filters fit many pipelines

• Easy to recombine: add, remove, or reorder filters

• Easy to test: feed a filter a small input, check its output

• Parallel: streaming filters can run at the same time

Cons of the pipe and filter style

• Format agreement: every filter must speak at the same data format

• Not interactive: poor fit for dialogs with a user

• Overhead: each filter may re-read and re-write the data

• Errors: a failure in the middle is awkward to report or recover

Monolithic app

Everything is built in one app

Service-oriented architecture (SOA)

An architectural style that organizes software into reusable services with well-defined interfaces. Services communicate to perform business functions and can be shared across multiple applications.

SOA vs. microservices?

Both organize systems into services. SOA emphasizes reusable services and integration across applications; microservices emphasize small, loosely coupled services that can be independently deployed and scaled, typically with their own data.

Microservices architecture

An architectural style that divides an application into small, loosely coupled services, each focused on one business capability. Services communicate through APIs or messaging and can be developed, deployed, and scaled independently, typically owning their own data.

How should microservice boundaries be drawn, and what is a bounded context?

Split by business capability, not technical layer. A bounded context is a part of the domain with its own language and data.

What boundary-design anti-pattern creates a distributed monolith?

Splitting the system into a UI service, logic service, and database service. Every feature touches all three, making them tightly dependent instead of independently changeable—a distributed monolith.