# **System Design & Architecture Notes**
**Unit 2, Module 1**
---
## **Objectives and Answers**
### **1. Relationship, Objectives, Inputs, and Outcomes of System Design**
- **Relationship**: System design connects analysis (requirements) to
implementation (code).
- **Objectives**:
- Define system structure, components, and interactions.
- Ensure the system meets functional and non-functional requirements.
- **Inputs**: Requirements specification, use cases, and analysis models.
- **Outcomes**: Architectural design, detailed design, and standards for
implementation.
### **2. Architecture and Architectural Styles in Software Development**
- **Architecture**: The fundamental organization of a system, including components,
relationships, and design principles.
- **Architectural Styles**:
- **Subsystems**: Group related components (client-server or peer-to-peer).
- **Layering**: Hierarchical abstraction (closed or open layers).
- **Model-View-Controller (MVC)**: Separates data (Model), UI (View), and logic
(Controller).
- **Service-Oriented Architecture (SOA)**: Components provide services over a
network.
- **Microservices**: Small, independent services working together.
- **Event-Driven Architecture (EDA)**: Components react to events.
### **3. Logical vs. Physical Design**
- **Logical Design**:
- Implementation-independent.
- Focuses on system functionality without platform details.
- Useful for re-implementation on different platforms.
- **Physical Design**:
- Implementation-dependent.
- Includes hardware/software specifics (e.g., middleware, databases).
### **4. Qualities and Objectives of Design**
A good design should be:
- **Functional**: Performs expected tasks correctly.
- **Efficient**: Optimizes time and resource usage.
- **Economical**: Cost-effective in terms of hardware/software.
- **Reliable**: Resilient to failures (hardware/software).
- **Secure**: Protects against attacks and unauthorized access.
- **Flexible**: Configurable for different scenarios.
- **Maintainable**: Easy to debug, modify, and enhance.
- **Reusable**: Components can be reused in other systems.
### **5. Measurable Objectives**
Examples:
- Performance metrics (response time, throughput).
- Scalability (number of users supported).
- Security compliance (e.g., POPI Act).
### **6. Selecting and Defending an Architecture**
- **Factors to Consider**:
- Project requirements (scalability, security).
- Existing systems (legacy integration).
- Cost and timeline.
- **Example**: For a scalable e-commerce system, microservices allow independent
deployment and scaling.
---
## **Database Management System (DBMS) Purpose**
- Acts as an intermediary between data and applications.
- Provides structured storage, retrieval, and manipulation of data.
- Ensures data integrity, security, and concurrent access.
### **Three Database Architecture Layers**
1. **Top Layer (API)**: Interfaces with external applications (e.g., JDBC, ODBC).
2. **Middle Layer**: Manages connectivity and data transformations.
3. **Data Layer**: Direct interaction with the database (provided by DBMS vendor).
---
## **HTTP Request/Response Cycle**
1. Client sends an HTTP request to the server.
2. Server processes the request (e.g., queries a database).
3. Server sends an HTTP response back to the client (e.g., HTML page).
### **8 Steps of Web-to-Middleware Communication**
1. Client browser requests a webpage.
2. Web server forwards the request to middleware.
3. Middleware processes the script (e.g., PHP, ASP.NET).
4. Middleware connects to the database.
5. Database executes the query and returns results.
6. Middleware formats results into HTML.
7. Web server sends the dynamic page to the client.
8. Client browser displays the page.
---
## **Static vs. Dynamic Web Systems**
| **Static Websites** | **Dynamic Websites** |
|---------------------|----------------------|
| Prebuilt HTML/CSS/JS pages. | Pages generated at runtime. |
| No server-side processing. | Uses server-side languages (PHP, Node.js). |
| No database interaction. | Can interact with databases (CRUD operations). |
---
## **Features of Web Application Servers**
- Extend web server functionality (e.g., database connectivity).
- Provide runtime environments for web apps.
- Support:
- Session management.
- Security (authentication).
- Business logic execution.
- Dynamic HTML generation.
- Transaction management.
---
## **Key Architectural Styles**
1. **Subsystems**: Client-server (one-way) or peer-to-peer (two-way).
2. **Layering**:
- **Closed**: Layer only uses the layer directly below.
- **Open**: Layer can use any lower layer.
3. **MVC**: Separates data, UI, and logic for maintainability.
4. **SOA**: Loose coupling, reusable services (e.g., web services).
5. **Microservices**: Small, independent services (scalable but complex).
6. **EDA**: Decoupled components react to events (resilient but hard to test).
---
## **Design Trade-offs**
- Example: Choosing between performance (microservices) and simplicity (monolith).
- Documentation is critical to justify decisions.
## **Software Engineering Standards**
- Improve quality, avoid errors, and ensure consistency.
- Examples: IEEE 1471-2000 (architecture), TOGAF (enterprise framework).
---
### **Summary**
- System design bridges analysis and implementation.
- Architecture styles (MVC, SOA, microservices) address different needs.
- Logical design is platform-agnostic; physical design depends on
hardware/software.
- Web systems use middleware for dynamic database interactions.
- Design qualities (scalability, security) guide architectural decisions.
---
**Key Terms**: DBMS, HTTP cycle, middleware, MVC, SOA, microservices, EDA,
static vs. dynamic websites.
