Department of CS & AI, School of CS & AI, SR University

Course Code Course Title LRP C Unit - 2 Lesson 1

r
[Link] Principles: Abstraction,
23CS201PC302 Software Engineering and 20 2 3 Decomposition, Modularity, Cohesion, 1. Introduction
System Design Coupling, Information Hiding
2. Layered
Program Core [Link] Styles: Layered, Client-Server, 3. Client-Server
MVC, Microservices vs Monolith
4. Model View Controller
3. Object-Oriented Design Review -UML:
Class, Sequence Diagrams; SOLID Principles

4. Design Patterns: Creational -Singleton,

Factory Method, Structural –Adapter
Dr. C Madan Kumar
[Link] -Observer, Strategy, Command
Associate Professor
6. Secure Coding Principles and Common
Vulnerabilities Overview -OWASP Top 10
awareness

09/15/2025 1
 Slide Title
Learning Outcome

By the end of this session, students will be able to:

 Differentiate among various architectural styles.

 Analyze trade-offs between monolithic and distributed architectures.
 Apply suitable architecture based on system requirements (size,
scalability, maintainability).
 Evaluate real-world case studies (e.g., Netflix, banking systems, e-
commerce platforms) to understand architecture selection.

09/15/2025 2
 Slide
Introduction Title
– Architecture Design

Why Architecture?
Software architecture is not the actual program but a blueprint of the system.
It allows engineers to verify if the design meets requirements, compare
different design options before coding starts, and minimize risks during
development and construction.

09/15/2025 3
 Slide
Introduction Title
– Architecture Design

 Why is Architecture Important?

Software architecture helps all stakeholders (developers, clients, users,

managers) communicate effectively.

It shows early design decisions that strongly affect later development and the
system’s success.

Architecture gives a clear, simplified model of the system structure.

It explains how different components are organized and work together.

09/15/2025 4
 Slide–Title
Introduction Design Style

Each architectural style defines a system category.

It includes:
Components (e.g., database, modules) that perform functions.
Connectors that allow communication and coordination between components.
Constraints that specify how components can be combined.
Semantic models that help designers understand system behavior from its parts.

Data-centered architectures
Data flow architectures
Call and return architectures
Object-oriented architectures
Layered architectures

09/15/2025 5
 IntroductionSlide Title of Software
– Definition

 Layered Architecture
The system is divided into layers, each with
specific responsibilities.
· User Interface Layer → Handles interaction
with users.
· Application Layer → Contains main application
logic.
· Utility Layer → Provides supporting services
(e.g., logging, configuration).
· Core Layer → The foundation of the system,
ensuring stability.
· Components exist within these layers and
interact through defined rules.

09/15/2025 6
 IntroductionSlide Title of Software
– Definition

 Layered Architecture

Online Food Delivery App (like Swiggy/Zomato)

· User Interface Layer → The customer uses the app to browse restaurants, add food to the cart, and place an
order.
· Application Layer → The app processes the order, manages payments, and sends notifications.
· Utility Layer → Services like login authentication, logging, and caching restaurant menus work in the
background.
· Core Layer → The system calculates prices, applies discounts, assigns a delivery partner, and manages
restaurant inventory.

Advantage: Easy to maintain because each layer has a clear responsibility.

Disadvantage: Slower performance since requests must pass through multiple layers.

09/15/2025 7
 IntroductionSlide Title of Software
– Definition

 Client-Server Architecture

Food Delivery App

Client → Swiggy/Zomato mobile app (used by customer to
place an order).
Server → Backend system that processes the order, checks
restaurant data, and sends confirmation.

🔹 Advantages
Centralized data and security (easy to manage).
Multiple clients can access the same server.

🔹 Disadvantages
If the server fails, clients cannot access services.
High load on the server may reduce performance.

09/15/2025 8
 Introduction – Slide Title
Data-centered architecture

University ERP System

Central Data (Repository) → Database with
Students, Courses, Fees, Exams.
Clients/Services → Admission system, Library,
Exam cell, Fee payment system all use the same
central database.

🔹 Advantages
Centralized data management avoids duplication.
Easy to share data across multiple systems.

🔹 Disadvantages
If the central data store fails, the whole system
stops.
High load on the repository can cause performance
issues.
09/15/2025 9
 IntroductionSlide Title architecture
– Data-flow
Online Food Delivery – Order Tracking
Input → Customer places an order.
Step 1 → Order details flow to payment processing.
Step 2 → Payment success data flows to order
management.
Step 3 → Order status flows to delivery allocation.
Output → Customer sees “Order on the way.”

🔹 Advantages
Easy to understand as data moves step by step.
Good for applications like compilers, data processing,
and signal processing.

🔹 Disadvantages
Not suitable for systems needing frequent user
interaction.
Hard to handle unexpected changes in data flow.

09/15/2025 10
 Introduction – Model View Slide Title
Controller

Model: Manages data and talks to the

database.
Database: Stores and provides data when
requested.
View: Displays the data to the user in a
dynamic way.
Controller: Directs requests and manages
flow—never works with data directly.

09/15/2025 11
 Introduction – Model View Slide Title
Controller

Model-View-Controller (MVC)
Online Banking Advantages:
System Organized: Clean separation makes code easier to
 Model → Stores customer details,
account balances, and transaction
manage.
records. Teamwork: Different people can work on different
 View → Web or mobile screens parts.
showing account balance,
transaction history, and transfer
Flexible: Change the look (View) without breaking the
forms. data (Model).
 Controller → Handles user
actions like “Login,” “Transfer
Money,” or “Download
Disadvantages:
Statement,” then updates the Complex: Can be too complicated for simple projects.
Model and View. Steep Learning: Harder to learn how the parts connect.
Bloat Risk: Controllers can become messy if misused.

09/15/2025 12
 Monolith vs Microservices Slide Title

1. Structural Coupling vs. Independence

•Monolith: All components (UI, business logic, data
access) are tightly coupled into a single, unified unit.
They are developed, built, and deployed together.
•Microservices: The application is broken down into a
set of loosely coupled, independent services. Each
service can be developed, deployed, and scaled
independently of the others.
2. Scaling Strategy
•Monolith: Scaling requires duplicating the entire
application across multiple servers, even if only one
specific feature is experiencing high load. This is
inefficient and costly.
•Microservices: Enables granular scaling. Only the
specific service that requires more resources can be
scaled independently, leading to much more efficient
09/15/2025 resource utilization. 13