Software Systems MidTerm

Difficulties of Software Engineering

• Complexity

• Conformity

• Changeability

• Invisibility

Requirements

• defines what a system must do to meet customer needs

• include functional goals & quality attributes

Functional Requirements

what the system should do - features

Non-Functional Requirements

how the system should operate - constraints

Non-Functional Requirement Examples

performance, availability, security, usability

Testing

checks whether a program produces expected results for given test cases

Types of Testing

• manual

• automated

Test Pyramid

bottom: unit tests (cheap)

middle: integration tests (middle)

top: end-to-end tests (slower, expensive)

Types of Automated Tests

• unit

• integration

• end-to-end

Maintenance

• corrective

• preventive

• adaptive

• evolutionary

• refactoring

Legacy Systems

• older systems with outdated technologies

• costly and risky to maintain

Processes

• activities followed when developing software

Approaches For Processes

• waterfall

• agile

Waterfall Approach

• requirements

• analysis

• design

• implementation

• tests

• deployment

-goes in that order. can’t go back without restarting.

Waterfall Approach Cons

• requirements change

• upfront specification takes time

• customers don’t know what they want

• documentation becomes outdated

ABC of Software Engineering (3 types of software)

• Type A: Acute

• Type B: Business

• Type C: Casual

Casual Software Systems

• small, low-criticality

• built by 1-2 devs

• risk of over-engineering

• vibe coding

Business Software Systems

• critical to the organization

• benefits from SE practices

• banking and financial systems

Acute Software Systems

• failure is unacceptable (human lives or major financial losses at stake)

• subway, aviation

• requires certification

Iterative Development

• frequent updates

• less emphasis on documentation

• customer involvement

Agile Methods

• provide a structure to agile ideas

• defines a lightweight process

Types of Agile Methods

• extreme programming

• scrum

• kanban

Extreme Programming Values

• communication

• simplicity

• feedback

• courage

• respect

• 40-hour week

Extreme Programming Principles

• economics

• continuous improvement

• failure happens

• baby steps

• personal responsibility

Extreme Programming Practices

• pair programming

• open scope contracts

Pair Programming

2 people, navigator and driver

Mob Programming

• entire team works on the same programming task

• collective learning, knowledge sharing

Software Contracts

• outsourcing devs requires a contract

• closed scope contracts

• negotiated scope contracts

Closed Scope Contracts

• deadline → defined by customer

• price and deadline → defined by supplier

Negotiated Scope Contracts

• scope defined per iteration, contract is renewable after each iteration

• customer involvement

Scrum

• sprints

• stakeholders → product owner → devs

• formal to informal specifications

• daily meetings

Sprints

• team implements user stories (features)

• product owner writes the stories

• problem-domain expert does as well

Product Owner

• writes user stories

• explain user stories to devs

• define acceptance tests

• prioritize user stories

Product Backlog

prioritized list of user stories and other work items

Characteristics of Product Backlog

• prioritized → highest-priority stories at the top

• dynamic → stories can be added or removed

Sprint Planning Steps

1. select sprint stories

2. break stories into tasks and assign them to devs

Scrum Team Layout

• small (basketball-football team size)

• includes 1 product owner and 1 scrum master

• cross-functional (devs, UX designers, data scientists)

Scrum Master

• helps team follow Scrum

• leader

• removes old technical impediments

• collects process metrics

Sprint Ending Review

• team presents sprint outcomes to PO and stakeholders

• each story is approved, partially approved, or rejected

• story returns to backlog if not

Sprint Ending Retrospective

• final sprint event

• reviews what went well and how to improve

Scrum Board

similar to a trello board

Story Points

• estimate story size empirically

• help determine what fits in a sprint

• fibonacci scale

Kanban

• no sprints

• no mandatory roles or events

• teams define their own roles and events

• pull a task to work on, complete task, repeat

Work in Progress Limits

• maximum number of tasks per step

• prevents team overload

• reflects team’s agreed capacity

Spiral Model (Non-agile process)

1. goals and constraints

2. alternatives and risk analysis

3. development

4. next iteration planning

Rational Unified Process (RUP)

plan and document with UML and CASE tool (company was acquired by IBM)

CASE

Computer-Aided Software Engineering

The 3 C’s of User Stories

• card

• conversations

• confirmation

Card (User Stories)

reminder for conversations during sprint

Conversations (User Stories)

communication with team

Confirmation (User Stories)

tests the product owner will perform to verify the story’s implementation (acceptance tests)

Characteristics of Good User Stories (INVEST)

• independent

• negotiable

• valuable

• estimable

• small

• testable

DoD

definition of done

Dogfooding

using/testing your own app

Feature Bloat

too many features

Use Cases

• detailed requirement specifications

• normal flow and extensions

  • extensions include exceptions and additional details for specific steps

Software Models

• bridge the gap between requirements and code

• documents solutions to problems defined by requirements

Types of Software Models

• formal: less common

• graphical: UML, most common

Unified Modeling Language (UML)

• proposed in 1995 to unify different modeling notations

• used as a blueprint or sketch

Unified Modeling Language (UML) As A Sketch

• common in agile methods

• lightweight, informal

• supports forward and reverse engineering

Forward Engineering

sketches are used to discuss alternative designs before coding

Reverse Engineering

sketches help explain existing code, for software maintenance and evolution

Types of UML Diagrams

• static diagrams: code structure (changes only when code changes)

• dynamic diagrams: runtime behavior (may vary across executions)

UML Diagrams

• activity diagram

• sequence diagram

• class diagram

• package diagram

UML Class Diagrams

• syntax includes class name, attributes, methods

Association

connects two classes with → in a class diagram

Multiplicity

connects two classes with → x..1 to represent how many of that class can have the other class

Common Multiplicities

• 0..1

• 1

• *

• 0..*

• 1..*

• n

Bidirectional Associations

connects two classes with ←> and has multiplicities

Inheritance

• connects to a class with a → (but arrow part is not filled in)

• ex: student → person

Dependencies

• represented by dashed arrows

• when a class uses an object, it ‘depends’ on that object

Sequence Diagrams

• behavioral dynamic diagrams that model objects and method calls between them

• review discord for image example

Return Arrows In Sequence Diagrams can be omitted when _

• return value is irrelevant

• method returns void

Modules

• the smaller parts resulting from the decomposition of the big problem

• AKA: packages, components, folders, layers

Design Properties

1. conceptual integrity

2. information hiding

3. cohesion

4. coupling

Design Principles

1. single responsibility

2. interface segregation

3. prefer interfaces to classes (dependency inversion)

4. prefer composition to inheritance

5. open/closed

6. demeter

7. liskov substitution

Conceptual Integrity

• everything looks the same

• user interface, design decisions, implementation decisions, technological decisions

Information Hiding

• classes hide their internal implementation details with the private modifier

Interface

set of public methods and attributes of a class

Cohesion

classes should have a single goal or single service

Coupling

• classes depend on each other

• call methods of other classes

• acceptable coupling (good)

• poor coupling (bad)

Acceptable Coupling

class A uses class B and:

• B provides a useful service to A

• B has a stable interface

• A interacts with B only via B’s interface

Poor Coupling

class A uses class B but:

• B’s interface is unstable

• A does not use B through its interface

Static (Structural) Coupling

• A’s code contains an explicit reference to B

• can be acceptable or poor

Evolutionary (Logical) Coupling

• A’s code contains no reference to B

• changes in B can impact A

• always poor coupling

Single Responsibility (SRP)

• each class has a single responsibility

• a class should only have one reason to change

Interface Segregation (ISP)

• interfaces should be small, cohesive, and tailored to each client

Dependency Inversion (DIP)

high-level code doesn’t depend on low-level details, both should depend on a shared interface

Prefer Composition to Inheritance

avoid unnecessary inheritance

Demeter

an object should have limited knowledge of the inner workings of other objects

Open/Closed (OCP)

a class should be open to extension but closed to modification

• parameters

• inheritance

• higher-order functions

• design patterns

Liskov Substitution Principle (LSP)

provides guidelines for redefining methods in subclasses

Design Patterns

• common solutions to recurring design problems

• shared vocabulary

• design reuse

• creational, structural, behavioral

Factory Design Pattern

• creational

• provides a single point of change if the code must be updated

Singleton Design Pattern

• creational

• ensures a class has only one instance throughout an application

• also provides a global access point of that instance

Proxy Design Pattern

• structural

• provides a placeholder object that controls access to a real object

• allows a request from a user to be interjected for security reasons

Adapter Design Pattern

• structural

• bridges two incompatible interfaces so they can work together

Facade Design Pattern

• structural

• a unified interface to a complex system of classes (hides internal intricacies)

Decorator Design Pattern

• structural

• dynamically adds new behaviors or responsibilities to individual objects without modifying original code

Strategy Design Pattern

• behavioral

• encapsulates a family of algorithms into separate classes which makes them interchangeable at runtime