# CS3219 Notes

## Lecture 1 - Software Dev Processes

### 1.1 Deployment Issues
- Integration of the internet and related advances
- Considerations: Shift towards cloud-nativity
- Quality => **Portability**

- Large-scale content delivery
- Data transfer btw end-points
- Considerations: Location, # of end-poitns, services quality
- Quality => **Availability, Performance**

- Heterogenous Platforms
- Variety of OS/Browser/Platforms Combinations
- Considerations: Coexistence of platforms and interoperability between platforms
- Quality => **Interoperability**

- Dependency and change management
- Components with interdependencies
- Considerations: Configurations, Version changes, Compatibility
- Quality => **Maintainability**

- Coordination & Communication
- Require coordination among components
- Considerations: API Design, Communication (Asyn/sync)
- Quality => **Performance**

- Security
- Privacy, Authentication, Authorization, Integrity
- Considerations: Encryption, Authentication and Authorization Management
- Quality => **Security, Usability**

### 1.2 Deployment Mechanisms
1. Bare Metal
2. Virtual Machines
3. Containers

#### 1.2.1 Bare Metal
- Installation and setup of an operating sys direclty on the **physical hardware** of a computer or server
- Offers MAX performance and resource utilization
- Factor affecting: Availability of libraries & Dependencies
- Trade off:
- Scalability & Flexibility
- Cost Factor
- Not Productivity -> Physical Isolation

#### 1.2.2 Virtual Machines (VM)
- Software-based emulation of a physcial computer.
- Able to run OS and execute software applications
- Use **Hypervisor** to create and manage VM
- Advantage:
- Lesser Cost
- Flexible
- Scalable
- High degree of Isolation
- Trade off:
- Susceptible to side-channel attacks
- Noisy neighbour problem -> If one VM takes out too many resources, other VM won't have enough resources to run the VM

#### 1.2.3 **Container**
- Lightweight, portable and efficient units
- Include only OS processes and necessary dependencies
- Do not require full OS
- Advantages:
- Consistently run across various computing env
- Granular & Controllable
- Provide a level of isolation
- Quick Setup
- Support DevOps Best practice (CI/CD)
- Can be used with orchestrator like Kubernetes

#### 1.2.4 Deployment Mechanism Model

### 1.3 Container vs Orchestrator
**Container**
- Provide platform for building and distributing services
- Limitations for Complex Applications
- Modular Approach -> Each handling specific task
- i.e: Docker

**Orchestrator**
- Automate the Deployment, scaling and management of containerized applications
- Integration and Coordination
- Scaling
- Fault tolerance
- Communication among containers
- i.e: Kubernetes

Tutorial 1: [here](https://docs.google.com/document/d/1esurTdVEqGdBwTpaXLIBJckPllySWrZ1Cw3qdAWRVM8/edit)

### Tut 1
1. What is the difference between container, image and container engine?
- **Container**
- Runtime instance of and image
- Contain the application or software itself
- Includes all necessary dependencies, packages to run the program
- Able to run on any device with the container engine
- **Image**
-

## Lecture 2 - Requirements and SDP
### 2.1 What are Requirements?
- A condition or **capability needed by a user** to solve a problem or achieve an objective
- **Capabilities that must be met or possessed** by a system
- Formal Statement that describes a **capability, feature, or constraint** of a software system

#### 2.1.1 SRS Components
1. Interfaces
2. Functional Capabilities
3. Perfomance Levels
4. Data Structures/Elements
5. Safety
6. Reliability
7. Security/Privacy
8. Quality
9. Constraints and Limitations

#### 2.1.2 SRS vs Project Backlog
**Software Requirements Specification (SRS)**
- Comprehensive document that outlines the FR and NFR
- In-depth description of a software product to be developed
- Typically associated with **traditional or Waterfall** development
- Produced at the **beginning** of the project, during **planning or initiation** phase

**Product Backlog**
- Dynamic and priortize of list of features, enhancements and incremental
- Keep changing with developing the product
- Contains **user stories or items** that represents specific functionality or improvements desired by users or stakeholders
- **Prioritization** is a key aspect, with higehr-priority items considered more critical for the product
- Continuously refined and adjusted throughout the development process
- Primarily associated with **Agile** methodologies, particularly **Scrum**

### 2.2 Types of Requirements
1. Business Req
2. User Req
3. Sys Req
4. Quality Req
5. Functional Req (FR)
6. Non-Functional Req (NFR)
7. Constraints
8. Data Req

#### 2.2.1 Business Req
- **Why the organization implement the system.**
- Goals, objectives and the needs of the organization (Vision and Scope Document)

#### 2.2.2 User Req
- **Goals or tasks the user must be able to perform with the product**
- Features and functionalities from user's perspectives
- Capture as **Use Cases, User Stories, Scenarios**

#### 2.2.3 Sys Req
- Description of overall sys behaviour and capabilities
- Encompass both FRs and NFRs
- Provide an understand of the **sys's scope and boundaries**

#### 2.2.4 Quality Req
- Req focus on quality attributes, such as performance, reliability, etc

#### 2.2.5 FRs
- Behavior of the product will exhibit
- What sys should do
- How it should respond to various inputs
- Functionalities that developer **must implement** for user to accomplish their tasks

#### 2.2.6 NFRs
- Description of characteristics that **do not relate directly to specific functionalities**
- Can include other attribute, such as sys performance
- i.e mean time between failure >= 9000 hours

#### 2.2.7 Constraints
- Limitations and restrictions that impact the development or operation of the software
- i.e: Budget, time, technology choices, and external dependencies

#### 2.2.8 Data Req
- Specifications related to handling, storage, and manipulation of data
- i.e data format, structures, sources, and the relationship between different data elements

### 2.3 Requirements development Process
`Elicitation` => `Analysis` => `Specification` => `Validation`

### 2.4 Quality Attributes of requirements
1. Availability => **External**
2. Performance => **External**
3. Efficiency => Internal
4. Scalability => Internal
5. Robustness => **External**
6. Safety => **External**
7. Security => **External**
8. Reliability => **External**
9. Integrity => **External**
10. Verifiability => Internal
11. Deployability => **External**
12. Compatibility => **External**
13. Installability => **External**
14. Portability => Internal
15. maintainability => Internal
16. Usability => **External**
17. Testability => Internal
18. Modifiability => Internal
19. Reusability => Internal
20. Interoperability => **External**

**Application Specific Quality Attributes**
1. Embedded Software -> Performance, Efficiency, Reliability, Robustness, Safety, Security
2. <mark>Web Applications -> Availability, integrity, interoperability, Performance, Scalability, security, usability</mark>
3. Desktop and Mobile software -> Performance, Security, usability

### 2.5 Software Development
#### 2.5.1 Software Development Life Cycle (SDLC)

#### 2.5.2 SDP Models
1. Waterfall
2. Spiral
3. Rapid Prototyping
4. Extreme Programming
5. Rational Unified Process
6. Test driven development
7. Agile (Scrum, Crystal)

### 2.5.3 When to use what?
1. Requirements are **well-understood, fixed and effor predictable** -> <mark>Waterfall model</mark>
- Stable requirements
- Familiar domain and solution
- Small portion at a time
- 

2. Fuzzy and evolving requirements -> <mark>Iterative and incremental development</mark>
- Through repeated cycles
- Small
- Types: Depth-First and Breadth-First
- 

### 2.6 DevOps
**Development + Operations**
- SD practices => Software development (Dev) + Operations (Ops)
- Increase committing efficiency while ensuring high quality

**Pipeline**
- Delivery Pipeline
- `BUILD` -> `TEST` -> `RELEASE`

- Feedback Loop
- `MONITOR` -> `PLAN`

**Benefits**
- [ ] Speed of Delivery
- [ ] Reliability
- [ ] Scale
- [ ] Improved Collab

Tutorial 2: [here](https://docs.google.com/document/d/1felCBS5re871pwHVGuGKRDKVXtGqwL8ynJewm5fN31Y/edit)

## Lecture 3 - Requirements

## Lecture 4 - Architecture

Tutorial 4: [here](https://docs.google.com/document/d/19vaDMiC1W6L9a332l10PBjZT081h-rtYJ4YDaIHDfmQ/edit)

## Lecture 5 - REST

### 5.1 What is REST Architectural Style
- Defines constraints for **transferring, accessing, and manipulating textual data representations** in a stateless manner across a network of systems

### 5.2 REST Architecture Constraints
- [ ] Code-on-demand
- [ ] Cacheable
- [ ] Stateless
- [ ] Uniform Interface
- [ ] Client-server
- [ ] Layered System

#### 5.2.1 Client Server
- **Principle**
- System divided into two separate entities: <mark>**clients and servers**</mark>
- **Reasoning**
- Separation of concerns
- Improve protability of user interface
- Improve scalability of server components
- Allows clients and servers to evolve independently

#### 5.2.2 Stateless
- **Principle**
- Server does not **store any information** about the client's state between requests
- Each request must contain all information needed to understand and process the request.
- **Reasoning**
- Enhance **reliability, scalability, and simplicity**
- Allow servers to treat each request independently
- Reducing the complexity of managing session state on the server
#### 5.2.3 Cacheable
- **Principle**
-
- **Reasoning**
#### 5.2.4 Layered System
- **Principle**
- **Reasoning**
#### 5.2.5 Uniform Interface
- **Principle**
- **Reasoning**
#### 5.2.6 Code on Demand
- **Principle**
- **Reasoning**

Tutorial 5: [here](https://docs.google.com/document/d/1oiijxFpzzXMGVGK3OFZlaVvuuIP6vGVqCAIqCsjvtIQ/edit)

## Lecture 6 - Microservices1

### 6.1 What is Microservice?

- Set of software applicatrions designed for limited scopre that work with each other
- Each microservice has minimal but **Well-Defined Capabilities** for the sake of creating a modularized overall architecture

### 6.2 Advantages of applying Microservices

- Organized around business capabilities
- Loosely coupled
- Owned by a small team
- Independently deployable (Service Instance per VM / Service Instance per Container / Service on a Host)
- Different pace of growth for different services
- Decentralized data management
- Scalability
- DevOps (CI/CD)

### 6.3 Monolithic VS Microservice

### 6.4 Domain Driven Design
- [ ] Ubiquitous Language
- [ ] Sub-domains
- [ ] Bounded Contexts
- [ ] Aggregates

### 6.5 Orchestration vs Choreography

<u>**Orchestration**</u>
1. **Centralized Control**
- A central controller or orchestrator in charge for coordinating and sequencing the interactions between services.
- **CLEAR FLOW OF CONTROL**

2. **Explicit Flow**
- Explicitly defined and managed by the orchestrator

3. **Single Point of Control**

<u>**Choreography/Pub-Sub**</u>
1. **Decentralized Control**
2. **Implicit Flow**
3. **Distributed Control**

<u>**Considerations**</u>
1. **Complexity and Flexibility**
- **Simplify** certain aspects of **development and maintenance** => <mark>**Orchestration**</mark>
- System require more **flexibility and autonomy** for individual services, allow to deploy/evolve independently => <mark>**Choreography**</mark>
2. **Communication**
- Involve **direct communication between orchestrator and each service**, enforcing a more structured and controlled communication pattern => <mark>**Orchestration**</mark>
- **Event-driven communication**, more loosely coupled and asynchronous interactions => <mark>**Choreography**</mark>
3. **Error Handling**
- **Centralized and easier to manage** => <mark>**Orchestration**</mark>
- Need to be **distributed across services**, requiring careful consideration => <mark>**Chereography**</mark>

### 6.6 Service Discovery
- API Gateway need to know the IP address and port of **each microservice**
- Patterns
- Client-side Discovery
- Server-side Discovery
- Service Registry

### 6.7 Service Communication

### 6.8 Patterns for Microservices design

1. DDD Patterns - Sub-Domains, Bounded Contexts, Aggregates
2. Deployment - Service instance per host, Service instance per Container
3. Service Routing/Collaboration - API Gateway, Orchestration, Choreography
4. Services Discovery - Client side, Server Side, Service Registry
5. Service Communication
- Sync => Request/Reply
- Async => Request/Async, Event-Driven, Pub-Sub Notification
6. Per service database

Tutorial 6: [here](https://docs.google.com/document/d/1OZKVrC1WmN6cbP3JowdIjMSzHRfAEcOh0nUFtswiDac/edit)

## Lecture 7 - Event Driven Architecture

### 7.1 What is Event?

#### 7.1.1 Definition
#### 7.1.2 Structure of Event
#### 7.1.3 Types of Event

### 7.2 Event Driven Architecture

### 7.3 Event Sourcing

## Lecture 8 - Communication Patterns

### 8.1 Synchronous vs Asynchronous Communication
#### 8.1.1 Synchronous Communication
1. **Definition**
- Sender and receiver of a message are synchronized in time.
- Sender send requests => wait for response before proceeding
2. **Characteristics**
- Sender blocks and waits for the response
- Usually <mark>Point-to-Point</mark>
- Immediate interaction
- Senders expect a timely response from the receiver
- Use in traditional request-response scenarios, <mark>HTTP request-response</mark> or <mark>function call</mark>
3. **Advantages**
- Simple to understand and implement
- Easier to reason about the flow of control in the application
4. **Disadvantages**
- Can lead to blocking, especially in scenarios where a response may be delayed
- Not suitable for scenarios with <mark>high latency</mark> or <mark>long-running operations</mark>

#### 8.1.2 Asynchronous Communication
1. **Definition**
- Communication that has lay between when a message is sent and when the receiver receives/interprets/responds
- Sender sends a message or request and **continues its operation without waiting** for an immediate response
2. **Characteristics**
- Sender does not block and wait for response
- Interaction is often message-driven
- No immediate response
- Use in the scenarios where responsiveness and scalability are important
3. **Advantages**
- Improve system responsiveness and scalability by allowing sender to continue processing other tasks
- Suitable scenarios: Unpredictable responses times or long-running operations
4. **Disadvantages**
- Requires additional mechanisms (callbacks, events, or polling) for the sender to receive the response
- The flow control is more complex
- Require careful handling to manage concurrency
- Race conditions might occur

### 8.2 Synchronous Request-Reply
#### 8.2.1 Remote-Procedure Call (RPC)

#### 8.2.2 HTTP/HTTPS

### 8.3 Asynchronous Request-Reply

### 8.4 Asynchronous Message Passing
#### 8.4.1 AMQP - Advanced Message Queueing Protocol

#### 8.4.2 Multi-Receiver

#### 8.4.3 Pub-Sub Pattern

#### 8.4.4 Single-Receiver (Point-to-Point)

### 8.5 Persistent vs Transient Communication
#### 8.5.1 Persistent Communication (Store and Forward)

#### 8.5.2 Transient Communication

Tutorial 8/9: [here](https://docs.google.com/document/d/1UCbZIuczBSKAPxrKKa60xQm72w0Q_R84EgzP19pxLn8/edit)

## Lecture 9 - Message Patterns

## Lecture 10 - Principle Pattern Entwinement

## Lecture 11 - Object Interation Design Patterns

## Lecture 12 - Recap