CSI3024

Software Application Architecture

By,
Dr.Swetha.N.G.,
Assistant Professor Senior,
Department of Analytics,
School of Computer Science and Engineering,
Vellore Institute of Technology, Vellore.

Email: [email protected] Mobile: 8903580808 Cabin: PRP 217-16

Guidelines to be followed
1. Be on time for class.
2. Be attentive and clarify your doubts immediately.
3. Don’t indulge in other actives when the class is in progress.
4. Complete the Assignments/Quiz within the deadline provided.
5. Maintain a dedicated notebook in class.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
Course Objectives
1. To understand the architectures, frameworks, design patterns and
its application architecture.
2. To understand the Core Java Design patterns, GOF, JEE Blue Print
patterns and principles.
3. Monolithic, Need of Micro services Architecture, MS
implementation, MS tools and technologies.
4. To understand what is an API, APIs classification and types,
Technology specific APIs, API Tools.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Course
Outcomes
After successfully completing the course the student should be
able to
CO1: Design an application components using the appropriate design
patterns (where, when, how and why).
CO2: Understand the difference between the Monolithic and
Microservices architecture with patterns.
CO3: Design an applications using Microservices architecture based
tools and technologies.
CO4: Analysis APIs for various types of services using different
technologies
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Modules
Module 1: Design Patterns
Module 2: Java Patterns
Module 3: Architecture Types & Microservices Architecture
Module 4: Microservices Architecture Tools and Technologies
Module 5: Microservices Design Patterns
Module 6: Introduction to API Tools and Technologies
Module 7: Batch and MQ Based Architecture

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Books
Recommended Text Book
1. Freeman, E., Robson, E., Bates, B., & Sierra, K., Head first design patterns:
A Brain-Friendly Guide - 10th Edition (Covers Java 8). " O'Reilly Media,
Inc.", 2016.
2. Fowler, M., Patterns of Enterprise Application Architecture, Addison-
Wesley, 2012
Reference Links
1. https://spring.io/projects/
2. https://microservices.io/
3. https://any-api.com/
4. http://www.corej2eepatterns.com/

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
Internal Assessment Pattern
Internal Component Total Mark Mark Consolidation Mode of Conduct
Digital Assignment 1 (Before FAT) 10 10 VTOP (Handwritten)
Quiz 1 (Before CAT 1) 10 10 MS Forms
Quiz 2 (Before CAT 2) 10 10 MS Forms
CAT 1 50 15 Offli ne Mode by COE
CAT 2 50 15 Offli ne Mode by COE
Total Internal Marks 60

CAT 1 – Module 1,2,3

CAT 2 – Module 4,5,6
FAT – Full Syllabus

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Additional Assignments
Additional Eligibility to Attend Total Marks of Components in which Mode of Conduct
Assignment Evaluation the marks will be
added
Improvement 1# Common to all 3 Quiz 1/ DA 1/ DA 2 Google Classroom
students
Remedial 1* Less than 15 in CAT 1 5 Quiz 1/ DA 1/ DA 2 Google Classroom +
Remedial 2* (Debarred students Offli ne Classes
will not be included)
Remedial 3*

Remedial 4* Less than 15 in CAT 2 5 Quiz 1/ DA 1/ DA 2 Google Classroom +

(Debarred students Offli ne Classes
Remedial 5*
will not be included)

* - Will be conducted only upon instructions from dean academics

# - Will be conducted only when the class average for Quiz 1 is below 5
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
WhatsApp Group
• B2 – Slot Whatsapp Groups
• Link for Whatsapp group will be sent to your official mail id after add and drop
of courses.

• Google Classroom
• Will be created and the link will be sent after add and drop of the course.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Module 1 - Design Patterns
Architecture Styles and Patterns, Design Patterns and Principles,
Frameworks, Architecture, Enterprise Architecture, Various
Architecture Design pattern, Patterns History, MVC Design Patterns,
Standards, Benefits.
(4 hours)

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
Software Application
• A software application is a computer program designed to perform a
specific function or set of functions for end-users.
• It's the tool that bridges the gap between human needs and
technological capabilities.
• From the simple word processor to the complex enterprise resource
planning (ERP) system, applications are integral to our daily lives and
businesses.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Characteristics of a Software
Application
1. User-Centric:
• Applications are designed to be used by people, whether it's a casual user or a
professional in a specialized field.
2. Purpose-Driven:
• Each application has a specific goal, such as creating documents, managing finances,
or controlling a machine.
3. Interactive:
• Applications typically involve user input and provide feedback or results.
4. Software-Based:
• They are programs executed by computers and rely on the underlying operating
system and hardware.
• Eg: Spotify
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Class Exercise
• For the given software's, analyse if the key characteristics of a
software application is satisfied.
• Spotify
• Whatsapp
• MS Word
• Google Classroom

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Software Application User-Centric Purpose-Driven Interactive Software-Based

Spotify Spotify's core purpose is to provide To provide on-demand access Users actively select music, A complex software system
an enjoyable music listening to a vast library of music and control playback, create handles music streaming,
experience. podcasts. playlists, and interact with content delivery, user data
recommendations. management, and more.
Whatsapp WhatsApp's core purpose is to To enable efficient and Users actively send/receive WhatsApp is a complex
facilitate communication and convenient communication messages, initiate calls, software system that handles
connection. between individuals and create groups, and share messaging, calls, media
groups. content. transfer, and user data.
MS Word MS Word's core purpose is to assist To enable users to create, Users actively type text, MS Word is a complex
users in creating and editing text edit, and format text format documents, insert software application that
documents. documents efficiently. images, and use various handles text processing,
editing tools. formatting, and file
management.
Google Classroom Google Classroom is designed To streamline classroom Teachers actively create Google Classroom is a cloud-
specifically for teachers and students management, facilitate assignments, post based application that relies
to facilitate learning and education. communication, and improve announcements, and provide on software for its
the learning experience for feedback. Students actively functionality, including
both teachers and students. submit assignments, assignment creation,
participate in discussions, and submission, grading, and
interact with learning communication.
materials.

All the 4 Software Applications are strongly aligned with Software Application
Characteristics !!!
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,
Vello re.
Software Application Architecture/
Software Architecture
• Software application architecture is the fundamental structure or
blueprint that guides the design and development of a software system.
• It involves
• Identifying and selecting the right components,
• Deciding how they should interact with each other, and
• Determining how they should be organized to achieve specific goals.
• To build a proper software the following has to be taken into
consideration,
• Architectural Style
• Architectural Pattern
• Design Pattern

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Software Architecture Styles and Patterns
• In software engineering, architectural styles and architectural patterns
provide a foundation for building software systems.
• They are both strategies to organize the components of a system in a way
that meets specific functional and non-functional requirements (e.g.,
scalability, performance, maintainability).
• Architectural Style refers to a broad category of system designs that share
certain common characteristics, like a set of rules for component
interaction, data flow, and how responsibilities are distributed.
• Architectural Pattern is a more specific solution within a particular
architectural style. It’s a proven design template or reusable solution to a
common architectural problem that can be applied in different contexts.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Software Architectural Style
• A set of principles that shapes the structure and behavior of software systems
through the use of predefined patterns, components, and interactions.
• Architectural styles define the high-level organization of a system and provide a
shared vocabulary for designing and discussing the system’s architecture.
• Architectural Style refers to a family of systems that share a common set of
characteristics, such as structural patterns, component types, and interaction
mechanisms.
• These styles provide a framework or blueprint for building a system's
architecture.
• Each architectural style specifies rules or constraints about how components
should interact, how data flows, and how system components should be
structured.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Need for Software Architectural Style
• Managing Complexity
• Architectural styles he lp break the system into smaller, manageable components (e.g., layers, modules, or
services).
• Promoting Reusability
• Many architectural styles en cou rage the use of standardiz ed components, which can be reus ed across
different systems.
• Ensuring Scalability and Performance
• Architectural styles like client-se rve r or microservices enable efficient distribution of tasks and resources,
allowing the system to scale more easily.
• Ensuring Maintainability and Flexibility
• A good architectural style promotes loose coupling between components, meaning that changes to on e part
of the system are less likely to affect others.
• Supporting Non-Functional Requirements
• Architectural styles often focus on achieving sp ecific non-functional requirements, such as performance,
reliability, security, and fault tolerance.
• Guiding Development Practices
• An architectural style provide s a consistent approach to structuring and designing a system, which is
especially important in large teams.
• Enabling Evolution and Future-Proofing
• As software require ments evolve, an architectural style he lps ensure that the system can adapt to these
changes with minimal disruption.
• Aligning with Organizational Goals and Constraints
• An architectural style he lps align the te chnical structure of the system with the business goals and
constraints.
 Categories of Software Architectural Styles
Category Types Category Types
Monolith Layered Architecture Data Centric Reposit ory Architecture
Monolithic Architecture Model-Vi ew-Control ler (MVC)
Data Fl ow Architecture
Distributed Client-Server Cloud and Scalable Serv erless Architecture
Peer-to-Peer (P2P) Microkernel Architecture
Microservi ces Architecture
Serv ice-Oriented Architecture
(SOA)
Event-Driven Architecture (EDA)
Component Based Component-Based Architecture Hybrid Hexagonal Architecture
Pipe and Fi lter Architecture CQRS
Call and Return Style Procedure Call
Remote Procedure Call

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
1. Monolithic Style
• These styles focus on building a single unified system where all
components are integrated into a single application.
• Layered Architecture:
• The system is divided into layers, each responsible for a specific concern (e.g.,
presentation, business logic, data access). Each layer communicates only with the
adjacent layer(s).
• Example: A typical 3-tier application (presentation layer, business logic layer, data
access layer).
• Monolithic Architecture:
• The entire application is built as a single unit, with tightly integrated components. It
can be simpler to develop initially but can become difficult to scale and maintain as it
grows.
• Example: Traditional single-server web applications.
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
2. Distributed Architectural Styles
• These styles emphasize distributing tasks and components across multiple
systems or machines.
• Client-Server Architecture (Distributed):
• A refinement of client-server where multiple clients interact with a central server
or group of servers, distributing work across different nodes.
• Example: Online banking systems or multiplayer games with a central server
managing multiple clients.
• Peer-to-Peer (P2P):
• A decentralized model where each node in the system acts as both a client and a
server. There is no central authority, and nodes communicate directly with each
other.
• Example: File-sharing systems like BitTorrent or decentralized blockchain networks.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
2. Distributed Architectural Styles
• Service-Oriented Architecture (SOA):
• Service-Oriented Architecture (SOA) is an architectural style that is used to design and
implement software systems where different components (services) interact with each
other over a network. Services are loosely coupled and communicate over a network,
often using standardized protocols like SOAP or REST.
• Example: Enterprise systems where different business services (e.g., accounting, HR) are
integrated via web services.
• Microservices Architecture:
• A distributed architecture where an application is broken down into small,
independently deployable services that can be developed, deployed, and scaled
separately.
• Example: E-commerce platforms with separate services for inventory, payment,
shipping, etc.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
2. Distributed Architectural Styles
• Event-Driven Architecture (EDA):
• Components communicate through the exchange of events, which trigger
actions in other components. It enables decoupling and supports
asynchronous communication.
• Example: Real-time applications like financial trading systems or order
processing systems.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
3. Component based Architectural Style
• These styles focus on assembling and integrating reusable software
components.
• Component-Based Architecture:
• The system is built by assembling pre-existing, self-contained components
that communicate with each other via defined interfaces. It promotes
reusability and separation of concerns.
• Example: Systems using frameworks like Eclipse RCP or .NET.
• Pipe and Filter Architecture:
• Components (filters) are connected through pipes, where each filter
processes data and passes it along the pipe to the next filter.
• Example: Unix shell scripting, data transformation systems, and stream
processing systems.
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
4. Data-Centric Architectural Styles
• These styles focus on managing data and its flow across the system.
• Repository Architecture:
• A central data repository is used to store shared data, and multiple components access and
modify the data.
• Example: Database-backed applications like CRM systems or content management systems.
• Model-View-Controller (MVC):
• This style separates an application into three interconnected components: the Model (data),
the View (UI), and the Controller (logic). This allows for separation of concerns and ease of
testing.
• Example: Web applications like Ruby on Rails or Angular applications.
• Data Flow Architecture: (Pipe Filter Style)
• Similar to pipe and filter, this style focuses on data moving through a series of processing
components, where each component operates on the data in a predefined way.
• Example: ETL (Extract, Transform, Load) systems or data processing pipelines.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
5. Cloud and Scalable Architectural Styles
• These styles are focused on managing the demands of scalability and
elasticity, often in distributed or cloud-based environments.
• Serverless Architecture:
• The application is broken into functions that are deployed in the cloud. The
cloud provider manages the infrastructure, scaling autom atically as needed.
• Example: AWS Lam bda, Google Cloud Functions for event-driven
applications.
• Microkernel Architecture:
• A core system (microkernel) provides basic functionality, and additional
features are added through plugins or extensions, allowing flexibility and
scalability.
• Example: IDEs like Eclipse or platforms like OSGi.
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,
Vello re.
6. Hybrid Architectural Styles
• These styles combine elements of multiple architectural approaches to
meet specific needs.
• Hexagonal Architecture (Ports and Adapters):
• This style separates the application core from external agents (e.g., databases, user
interfaces, and external services). The core interacts with the outside world
through well-defined "ports" and "adapters."
• Example: Applications designed to integrate with multiple external systems (e.g.,
banking applications).
• CQRS (Command Query Responsibility Segregation):
• Separates the reading of data (queries) from the writing (commands) to optimize
both operations independently, usually in event-driven systems.
• Example: Systems that require highly responsive read models (e.g., e-commerce
platforms).
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
7. Call and Return Architectural Style
• The Call and Return architectural style refers to a design pattern where a
system is organized such that a component (the caller) sends a request to
another component (the callee) and waits for a response.
• Procedure Call Architecture
• In this style, a process or program sends a call to another procedure or function and
waits for the result. This is one of the most common forms of Call and Return and is
widely used in procedural programming languages (e.g., C, Pascal).
• Remote Procedure Call (RPC)
• In RPC, a procedure or function in a program can call a function that resides on a
remote server (possibly on a different machine or node), and the client waits for a
response. This is a more distributed version of the procedure call style.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Can you combine more than 1 style in
a software application?
• Yes, a software system can have more than one architectural style.
• This is common in complex systems where different parts of the
system have unique requirements that are best addressed by
combining multiple styles.
• Eg: E-Commerce Platform

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
Can you combine more than 1 style in a
software application?
Style Need
Layered Architecture The system uses layers such as presentation, business logic, and data
access to manage responsibi lities.
Microservices Architecture Individual functionalities, such as product search, payment processing,
and recommendations, are built as independent microservices.
Event-Driven Architecture Events like inventory updat es, order placement, and notifications are
processed asynchronously using messaging systems.
Client-Server Architecture The front-end application (client) communicates with the back-end
(server) to fetch product details, process payments, etc.
Service-Oriented Architecture The platform might use SO A to integrate older inventory systems or
(SOA) payment gateways.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Why Combine Multiple Styles?
• Each architectural style solves a specific problem:
• Scalability: Microservices make it easier to scale individual
components.
• Real-Time Processing: Event-driven architecture ensures
responsiveness.
• Separation of Concerns: Layered architecture simplifies development
and maintenance.
• Interoperability: SOA allows integration with existing systems.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Software Architectural Pattern
• A software architectural pattern is a general, reusable solution to a
commonly occurring problem in software architecture within a given
context.
• It is a description of the elements of a system, their responsibilities,
and the relationships between them.
• The pattern provides a template that can be instantiated in many
different ways.
• Eg: Web Browsers – Client Server Architecture – Client Server
Architectural Pattern

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
 Key characteristics of software
architectural patterns
• Generality: Applicable to a wide range of systems, not specific to a
particular domain or technology.
• Reusability: Can be applied repeatedly in different projects with variations.
• Context: The pattern is not a one-size-fits-all solution. It must be adapted to the
specific needs and constraints of the project.
• Problem-solution: The pattern addresses a specific architectural problem
or concern, such as scalability, maintainability, or performance.
• Documented: The pattern is typically described in a well-defined format,
including a name, description, context, forces, solution, and consequences.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
 10
Types of Software Architectural Patterns
Type Description Advantage Disadvantage
Layered 1. Components(code) in this pattern are • Scalability • Complexity
Architecture separated into layers of subtasks and • Flexibilit y • Performance
Pattern they are arranged one above another. • Maintainability Overhead
2. Each layer has unique tasks to do and all • Strict Layer
the layers are independent of one Separation
another.
Client-Server 1. The client-server pattern has two major • Centralized • Single Point of
Architecture entities. Management Failure
Pattern 2. They are a server and multiple clients. • Scalability • Costly
Here the server has resources(data, files • Security • Complexity
or services) and a client requests the
server for a particular resource.
3. Then the server processes the request
and responds back accordingly.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Types of Software Architectural Patterns
Type Description Advantage Disadvantage
Event-Driven 1. Event-Driven Architecture is an agile • Scalability • Compl exity
Architecture approach in which services (operations) • Real-time • Compl ex Testing
Pattern of the software are triggered by events. Processing • Reliability
2. When a user takes action in the • Flexi bility
application built using the EDA approach,
a state change happens and a reaction is
generated that is called an event.
Microkernel Microkernel pattern has two major • Flexi bility • Compl ex
Architecture components. • Scalability Communicat ion
Pattern They are a core system and plug-in modules. • Maintainability • Lack Built-in
1. The core system handles the Functionalities
fundamental and minimal operations of • Compl ex Design
the application.
2. The plug-in modules handle the
extended functionalities (like extra
features) and customized processing.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
 Types of Software Architectural Patterns
Type Description Advantage Disadvantage
Microservices 1. The collection of small services that are • Scalability • Complex
Architecture combined to form the actual application • Faster Delivery Management
Pattern is the concept of microservices pattern. • Easier • Network Congestion
2. Instead of building a bigger application, Maintenance • Security
small programs are built for every service
(function) of an application
independently.
3. And those small programs are bundled
together to be a full-fledged application.
Space-Based 1. Space-Based Architecture Pattern is also • Scalability • Complexity
Architecture known as Cloud-Based or Grid-Based • Performance • Cost
Pattern Architecture Pattern. • Flexibilit y • Network Latency
2. It is designed to address the scalability
issues associated with large-scale and
high-traffic applications.
3. Thi s pattern is built around the concept
of shared memory space that is accessed
by multiple nodes Sw.etha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
 Types of Software Architectural Patterns
Type Description Advantage Disadvantage
Master-Slave 1. The Master-Slave Architecture Pattern is • Scalability • Single Point of
Architecture also known as Primary-Secondary • Fault Tolerance Failure
Pattern Architecture. • Performance • Complex
2. It involves a single master component Communication
and that controls multiple slave • Latency
components.
3. This is often used for parallel processing
and load distribution.
Pipe-Filter 1. Pipe-Filter Architecture Pattern structures • Reusability • Debugging Difficulty
Architecture a system around a series of processing • Scalability • Data Format
Pattern elements called filters that are connected • Parallelism constraints
by pipes. • Latency
2. Each filter processes data and passes it
to the next filter via pipe.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
 Types of Software Architectural Patterns
Type Description Advantage Disadvantage
Broker 1. The Broker architecture pattern is • Scalability • Complex
Architecture designed to manage and facilitate • Flexibilit y Implementation
Pattern communication between decoupled • Fault Tolerance • Single Point of
components in a distributed system. Failure
2. It invol ves a broker that acts as a • Security Risks
intermediary to route the requests to the
appropriate server.
Peer-to-Peer 1. The Peer-to-Peer (P2P) architecture • Scalability • Security Risks
Architecture pattern is a decentralized network model • Fault Tolerance • Data Consistency
Pattern where each node, known as a peer, acts • Cost Efficiency • Complex
as both a client and a server. Management
2. There is no central authority or single
point of control in P2P architecture
pattern. Peers can share resources, data,
and services directly with each other.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Considerations for choosing the
right Architectural Pattern
• Scalability: How well the system need to scale with the increasing load?
• Performance: Are there any specific performance requirements such as
low latency?
• Availability: Does the system need to be fault-tolerant?
• Security: What are the security requirements of the system and what are
the potential threats?
• Budget: What are the budget constraints for the development and the
maintenance of the system?
• Tools and Technology Stack: What technology and tools will be required?

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Knowing the difference !!!
• The Pipe and Filter Style provides a general blueprint for how to organize a system
around data processing.
• The Pipe and Filter Pattern offers a specific, proven way to implement that style, such
as using Unix pipelines or defining clear interfaces for data exchange between filters.
• By understanding these distinctions, you can choose and apply appropriate architectural
approaches to your software projects more effectively.
• Eg: E-Commerce
• Search Feature
• Order Placement
• Order Placement by Clien t
• Order receiving How to arrange the Filters?
• Order Parsing
Upstream Filter/ Downstream Filter?
• Order Validation
• Order Placing How to implement it?
• Shipping

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Difference
between
Architectural
Style and
Architectural
Pattern
Design Patterns
• Design patterns are general repeatable solutions to commonly
occurring problems in software design.
• They aren’t templates or actual code, but more like guidelines to
solve a particular problem in a certain way.
• It can be considered as a general concept for solving a particular
problem.
• We can follow the pattern details and implement a solution that suits
the realities of your own program.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Design Patterns
• Most patterns are described very formally so people can reproduce
them in many contexts.
• Here are the sections that are usually present in a pattern
description:
• Intent of the pattern briefly describes both the problem and the solution.
• Motivation further explains the problem and the solution the pattern makes
possible.
• Structure of classes shows each part of the pattern and how they are
related.
• Code example in one of the popular programming languages makes it easier
to grasp the idea behind the pattern.
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
History of Patterns
• Patterns are typical solutions to common problems in object-oriented design.
• When a solution gets repeated over and over in various projects, someone
eventually puts a name to it and describes the solution in detail.
• That’s basically how a pattern gets discovered.
Name History
Christopher Alexander He observed recurring solutions to common probl ems
(1970) in architecture and described them as patterns.
Kent Beck and Ward Exploring the application of patterns to software
Cunningham (mid 1980) design
Erich Gamma et al (1994) Gang of Four (GOF) – 23 design pattern
Late 1990s-2000s Patterns are widely adopted with frameworks and
programming practices.
2010s-Present Design patterns evolv e for distributed systems,
functional programming, and cloud-native applications.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
 Why Learn Patterns?
• Design patterns are a toolkit of tried and tested solutions
to common problems in software design.
• Even if you never encounter these problems, knowing patterns is
still useful because it teaches you how to solve all sorts of
problems using principles of object-oriented design.
• Design patterns define a common language that you and
your teammates can use to communicate more efficiently.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
Classification of
Patterns
• Creational patterns
• Provide object creation mechanisms that increase flexibility and reuse of
existing code.
• Structural patterns
• Explains how to assemble objects and classes into larger structures, while
keeping these structures flexible and efficient.
• Behavioral patterns
• They take care of effective communication and the assignment of
responsibilities between objects.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Design Principles

• Design principles represent high-level guidelines or best practices

that software developers should consider while designing system
architecture.
• They are broad concepts that can guide decisions, rather than
specific solutions to problems.
• There are many design principles, that are listed here:
• Keep it Simple, Stupid
• Don’t Repeat Yourself (DRY)
• You Aren’t Gonna Need It (YAGNI)
• Tell, Don’t Ask (TDA)
• SOLID
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
1. Keep it Simple, Stupid
• Simplicity triumphs over complexity.
• Direct and clear codes are better for developing, maintaining, and scaling,
turning simplicity into a form of efficiency.
• The KISS principle advocates for straightforward and uncomplicated
solutions over unnecessarily complex ones.
• It suggests that the best designs are often the simplest ones, as long as
they effectively meet the desired goals.
• Simpler Design induces the following,
• Reduced Complexity
• Faster Development
• Better Maintainability

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Unnecessarily Complex Simple Solution

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
2. DRY (Don’t Repeat
Yourself)
• The DRY principle is a fundamental software development principle
that advocates for avoiding code duplication.
• It aims to reduce redundancy by ensuring that a single piece of
functionality or logic is implemented only once.
• This makes the code more maintainable, easier to read, and less
prone to errors.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
 Without DRY Principle !!!

• The logi c for calculating areas is

repeated.
• If the formula needs to change, you
must update it in multiple places,
increasing the risk of
inconsistencies.
• Makes the code harder to maintain
and debug.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
 With DRY Principle !!!

1. Single Source of Truth: The area calculation

logic exists in one place, ensuring consistency.
2. Maintainability: If the formula changes (e.g.,
adding a tolerance factor), you only need to
update it in one location.
3. Reusability: The methods can be reused
throughout the program, reducing redundancy .

Dr.Swetha.N.G., Assi stant Pro fes sor Se nior, SCOPE, VIT, Vello re.
3. You Aren’t Gonna Need It (YAGNI)
• Do not add functionality unless you are sure it is needed.
• Avoid creating functions that are not essential.
• Focus on what is really necessary, keeping the code simple and
direct.
• The YAGNI practice is important for two main reasons:
• Time Savings: You stop spending time developing functions that you may
never use.
• Cleaner Code: Your code becomes clearer and free of assumptions that often turn
out to be wrong.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
Violating YAGNI !!!
• The trackEmployeeProject s() and logEmployeeHist ory() methods were added
prematurely before any requirement.
• They clutter the code, increase complexity, and are not currently needed.
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
 Applying YAGNI !!!
• The code is simpl er and easier to maintain.
• No unnecessary methods or placeholders clutt er the
code.
• If a requirement arises in the future (e.g., tracking
employee projects), it can be added only when
necessary.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
4. Tell, Don’t Ask (TDA)
• This principle emphasizes that objects should be responsible for their
own behavior.
• Instead of asking an object for its state and then making decisions
based on that state, you should directly "tell" the object what to do.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
 Violating TDA !!!

The code asks for the state of an object (balance) and

makes decisions outside the object.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
 Applying TDA !!!

• The BankAccount class encapsulates its

behavior (checking balance and updat ing
it).
• The Main class doesn’t ask for the balance
explicitly—it simply tells the withdraw
method what to do.
• Reduces duplication of logic: If
withdrawal rules change, they are
updat ed in one place (inside
BankAccount).
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
5. SOLID
• The SOLID principles are five key design principles for building
maintainable, scalable, and testable object-oriented software.
• These principles were introduced by Robert C. Martin and are widely
used in software design to promote clean code architecture.
• Single-responsibility principle (SRP)
• Open–closed principle (OCP)
• Liskov substitution principle (LSP)
• Interface segregation principle (ISP)
• Dependency inversion principle (DIP)

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
5.1 Single Responsibility Principle (SRP)
• A class should have only one reason to change, meaning it should
have only one responsibility.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
5.2 Open/Closed Principle (OCP)
• Software entities (classes, methods,
modules) should be open for extension
but closed for modification.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
5.3 Liskov Substitution Principle (LSP)
• Objects of a superclass should be
substitutable by objects of their subclasses,
and the application should still function as
expected.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
5.4 Interface Segregation
Principle (ISP)
• A class should not be forced to implement
interfaces it does not use.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
5.5 Dependency
Inversion Principle
(DIP)
• High-level modules
should not depend on
low-level modules. Both
should depend on
abstractions (interfaces).

• Switch is tightly coupled

to LightBulb and
Fan.Adding a new device
(e.g., AirConditioner)
requires modifying the
Switch class.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Class
Exercise
Is the given snippet of code
SOLID Design Principle
compatible? Justify your
response. Also write the SOLID
compatible refactored code and
justify its compatibility.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
 Class Exercise
Violations Description
Single Responsibility Class Invoice has
Principle (SRP) multiple responsibi lities
Open Closed Principle There is no possi bility to
(OCP) extend the Discount
process.
Dependency Inversion Invoice (High Level
Principle (DIP) Module) is dependent
on print Invoice() and
saveToDatabase() which
can be considered as
low level modul e.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Solution

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
 Violations Description
Single Responsibility Principle (SRP) The Invoice class is responsible only for managing invoice data.
Discount calculation and saving are handled by separate classes.
Open Closed Principle (OCP) New discount strategies can be added by implementing the
DiscountStrategy interface without modifying the Invoice class.
Liskov Substitution Principle (LSP) Any class implementing DiscountStrategy or InvoiceRepository can be
used interchangeably without breaking the application.
Interface Segregation Principle (ISP) The Invoice class depends only on interfaces (DiscountStrategy and
InvoiceRepository) that it actually uses.
Dependency Inversion Principle (DIP) High-level modules (Invoice) depend on abstractions (DiscountStrategy
and InvoiceRepository), not on concrete implementations.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
Homework
• Is the given snippet of
code SOLID
compatible? Justify
your response. Also
write the SOLID
compatible refactored
code and justify its
compatibility.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Framework
• A software framework is like a blueprint or a skeleton for building
software applications.
• It provides a pre-defined structure, tools, and libraries that
developers can use to streamline the development process.
• Instead of starting from scratch, developers can leverage the
framework's components to focus on the unique aspects of their
application.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components of a Software Framework
• Libraries: Pre-written code modules that handle common tasks, such
as data manipulation, network communication, and user interface
elements.
• APIs (Application Programming Interfaces): A set of rules and
protocols that allow different software components to interact with
each other.
• Tools: Utilities that aid in development, testing, and debugging, such
as code editors, debuggers, and testing frameworks.
• Best Practices: Guidelines and conventions that promote code
maintainability, reusability, and efficiency.
Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Types of Software Frameworks
• Web Frameworks:
• Us ed for building web applications, such as webs ites and web services.
• Example s include Djan go (Python), Ruby on Rails (Ruby), and Express.js (Node.js).
• Mobile App Frameworks:
• Us ed for developing mobile applications for various platforms.
• Example s include React Native, Flutter, and Xamarin.
• Game Development Frameworks:
• Us ed for cre ating video games.
• Example s include Unity, Unreal Engine , and Godot.
• Data Science Frameworks:
• Us ed for data analysis, machine learning, and data visualization.
• Example s include TensorFlow, PyTorch, and Scikit-learn.
• Desktop Development Frameworks:
• Us ed for cre ating system utilitie s and tools that enhance the functionality and performance of desktop
computers
• Electron (JavaScript),Qt (C++), Java, Python

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
Benefits of Using a Software Framework
• Faster Development: Frameworks provide pre-built components
and tools, reducing the time required to develop applications.
• Improved Code Quality: Frameworks often enforce best practices
and conventions, leading to more maintainable and reliable code.
• Enhanced Productivity: Developers can focus on the
application's specific logic rather than reinventing common
functionalities.
• Better Security: Many frameworks include built-in security
features, such as input validation and authentication mechanisms.
• Larger Community Support: Popular frameworks have
active communities that provide resources,
tutorials, and support.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Choosing the Right Framework
• The choice of a software framework depends on various factors,
including:
• Project requirements: The specific features and functionalities
needed for the application.
• Development team's expertise: The programming languages and
technologies that the team is familiar with.
• Performance requirements: The need for high performance and
scalability.
• Community support: The availability of resources, tutorials, and
active community forums.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Example
Let’s say you're tasked with developing a shopping app for a clothing
store. The app should be available for both iOS and Android platforms,
feature real-time product updates, secure payment integration, and
allow users to browse items, add to cart, and checkout. Additionally,
the store wants the app to be fast, user-friendly, and have a high-
quality design. Provide a step by step guidance regarding the choice of
framework.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
1. Define Key Requirements
• Cross-platform or Native: The app needs to run on both iOS and
Android, so you have to decide between:
• Native development (using Swift for iOS and Kotlin/Java for Android)
• Cross-platform development (using a framework to build once and deploy on
both platforms)
• Performance: Since it’s an e-commerce app, performance is critical
for smooth browsing, real-time updates, and fast payment
processing.
• User Experience: Design plays a big role in an e-commerce app, and
you need an intuitive UI with good animations and smooth
transitions.
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,
Vello re.
2. Evaluate Framework Options
• Native Development:
• Swift (iOS) + Kotlin/Java (Android)
• Pros: Best performance and user experi ence, full access to nat ive device features.
• Cons: Dev elopment effort and cost increase because you need to build and maintain two separate
codebases.
• Cross-platform Frameworks:
• Flutter:
• Pros: Single codebase for both iOS and Android, great performance (compiled to native code), excellent UI with
pre-built widgets, hot reload for fas ter development.
• Cons: Newer than React Native, so some features might require extra work or be less mature.
• React Native:
• Pros: Matu re, popular, and widely used. Single codebase, good performance, can use native modules for
specific tasks.
• Cons: Slightly lower performance compared to Flutter for complex animations or real-time updates, but still
good enou gh for mo st e-commerce apps.
• Xamarin:
• Pros: Based on C#, great for Microsoft ecosys tem, single codebase.
• Cons: Les s pop ular than Flutter and React Native, which could impact the availability of resources or
community support.
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
3. Consider the Developer’s Skillset
• If your team is already proficient in JavaScript, then React Native is
an excellent choice because it will be easier for them to get started.
• If your team is more experienced in Dart or enjoys creating visually
rich apps, Flutter might be the better option.
• If your team has strong experience in C# and is familiar with the
Microsoft ecosystem, Xamarin could be ideal.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
4. Consider Performance Needs
• For an e-commerce app where the app needs to be fast and
responsive (especially when handling images, product updates, and
user interactions), Flutter is a strong choice because of its near-native
performance and high-quality UI capabilities.
• If the app requires real-time interactions (e.g., live stock updates or
payment processing), Flutter’s performance and the ability to use
native modules can be beneficial. React Native can also handle this
well but may require optimizations for certain use cases.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
5. Evaluate Long-Term Maintenance
• React Native and Flutter both have large, active communities
and good documentation, ensuring easier long-term
maintenance and the availability of third-party libraries for
payment integrations, security features, etc.
• Native development might require more effort to maintain
separate codebases for iOS and Android, but it offers the highest
level of customization and performance.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
6. Consider Design and User Experience
• Flutter excels in UI design, providing a wide range of pre-built
widgets that replicate the native look and feel across both platforms.
It’s great for apps that require a highly polished, custom UI.
• React Native also supports custom UI components but may require
additional effort to achieve the same level of design consistency
across platforms as Flutter.
• If design and user experience are paramount, and you're willing to
invest more time in fine-tuning the user interface, Flutter would be
an excellent choice.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Final Decision

• Based on the requirements of the shopping app, Flutter appears to

be the most suitable choice because:
• It supports cross-platform development, saving time and cost.
• It provides high performance and a rich UI, essential for an e-commerce app
with many product images and interactive elements.
• It allows for real-time updates, which is essential for inventory management
and order processing.
• Its growing popularity and developer community ensure long-term
maintainability and support.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Enterprise Architecture
• Enterprise Architecture (EA) is a strategic framework that
organizations use to align their business goals, processes, and
technology infrastructure with their overall objectives.
• It provides a comprehensive view of the entire organization and aims
to improve efficiency, agility, and alignment between business and IT.
• EA serves as a blueprint for managing complex business and IT
transformations, ensuring that the technology stack, processes, and
systems are all working towards common goals.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Components of Enterprise Architecture
• Business Architecture:
• Focuses on aligning business processe s, organizational structure, and business goals with the IT systems.
• It he lps de fine how the bu siness op erates and what capabilitie s are ne eded to achieve strategic objectives.
• Information Architecture:
• Deals with the management of data and information within an enterprise.
• It includes how data is stored , access ed, and share d across systems, en suring that the informatio n is accurate,
consistent, and easily retrievable.
• Application Architecture:
• Defines the softw are applications and the ir interactions.
• It estab lish es how applications support bu siness process es and how they integrate with oth er systems and
data sources.
• Technology Architecture:
• Focuses on the underlying IT infrastructure (e.g., hardware, ne tworks, operating systems, cloud platforms)
and how it su pports the organiz ation's applications and bu siness proce sses.
• Security Architecture:
• Ens ures that the ente rpris e's data, applications, and systems are secure, focusing on privacy, authentication,
authoriz ation, and overall cybersecurity.
• Governance:
• Involves cre ating policies, standards, and guide lines that ensure the architecture is followed consistently
across the organiz ation.
• Governance also includes de cision-making process es related to arch ite cture evolution , risk management, and
compliance. Dr.Swetha.N.G., As sistant Professor Senior, SCOPE, VIT, Vellore.
Benefits of Enterprise Architecture
• Alignment of Business and IT: EA ensures that IT systems and resources are aligned with
business goals and strategies, preventing misalignment and inefficiencies.
• Improved Efficiency: EA identifies areas where processes, systems, and technologies can
be streamlined or optimized, reducing redundancy and improving overall operational
efficiency.
• Cost Reduction: By eliminating redundancies and optimizing the IT portfolio, EA helps in
reducing costs related to software, hardware, and support.
• Better Decision-Making: EA provides a holistic view of the organization, allowing
leadership to make more informed decisions regarding technology investments, process
changes, and risk management.
• Agility and Flexibility: EA allows organizations to be more adaptable to changes in the
market, customer needs, or technology by providing a scalable and flexible foundation
for growth and innovation.
• Risk Management: EA helps identify and mitigate risks related to technology, security,
and compliance by providing a clear understanding of the architecture and its
components.
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Frameworks in Enterprise Architecture 4

Framework Description Key Elements

TOGAF (The Open Group A comprehensive EA framework that Architecture Vision, Business
Architecture Framework) provi des a detailed methodology Architecture, Information Systems
(Architecture Development Method or Architecture (Data and
ADM) for developing, maintaining, and Application), Technology
managing EA. Architecture, and Opportunities
and Solut ions.
Zachman Framework Classification-based framework that helps It includes six perspectives
organize and structure architectural (Planner, Owner, Designer, Builder,
artifacts in a matrix format. Subcontractor, and Enterprise) and
six aspects (What, How, Where,
Who, When, and Why), provi ding a
comprehensive view of the
enterprise.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Key Frameworks in Enterprise Architecture
Framework Description Key Elements
FEAF (Federal Enterprise Developed by the U.S. federal It emphasizes the alignment of
Architecture Framework) government, FEAF is used to guide the technology with business
architecture of large government processes and promotes
organizations. standardization across the
organization.
Gartner Enterprise Focuses on providing practical guidance for Simplified approach that integrates
Architecture Framework creating and evolv ing EA, emphasizing the business strategy with IT
need for an agile and flexible approach. capabilities to drive business value.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Enterprise Architecture Process
• Developing the Vision: The first step in EA is understanding the organization's
mission, goals, and strategic direction. This vision will guide all subsequent
architectural decisions.
• Current State Assessment: EA starts with assessing the current state of the
organization, including its existing systems, processes, technologies, and
organizational structures.
• Target State Definition: Based on the vision and business goals, the target state
describes what the organization aspires to achieve in terms of business
processes, technology infrastructure, and capabilities.
• Gap Analysis: This step identifies the differences between the current state and
the target state, including the gaps in processes, technology, and capabilities.
• Architecture Design: The design phase involves creating blueprints and models
for the enterprise's architecture, addressing the identified gaps and ensuring
alignment with the business goals.
• Implementation: The final step involves executing the architecture plan,
including transitioning to new technologies, systems, and processes while
ensuring minimal disruption to operations.
Challenges in Enterprise Architecture
• Complexity
• Resistance to Change
• Lack of Skilled Professionals
• Evolving Technology Landscape
• Alignment with Business Goals

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Case Study

• XYZ Electronics is a small e-commerce business that sells electronic gadgets and accessories
online. The company has been growing steadily over the past few years, and the founders want
to scale the business further. However, they face several challenges:
• Manual Processes: The business currently handles inventory, orders, and customer management
manually or using disparate systems that don't integrate with each other.
• Limited Visibility: There is no centralized data view. Customer data, orders, and inventory
are stored separately, making it difficult for the staff to access real-time information.
• Scalability Issues: As the business grows, the existing IT infrastructure is struggling to handle
the increasing number of customers, transactions, and product listings.
• The business owners realize that in order to grow efficiently, they need a more cohesive
and scalable architecture that integrates their business processes and IT systems.

Elaborate on how you can apply the enterprise architecture to provide solution to the above
given scenario.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Step 1
• Goal:
XYZ Electronics wants to implement an enterprise architecture (EA) strategy to:
1. Streamline business processes by integrating systems.
2. Improve operational efficiency and decision-making.
3. Create a scalable IT infrastructure that supports growth.
4. Enhance customer experience through data-driven insights and automation.
• Architectural Vision:
• The business owners and key stakeholders (IT, marketing, sales, and operations) meet to
discuss the vision for the future of XYZ Electronics. They agree on the following priorities:
• Integration: Connect inventory, order management, and customer relationship management
(CRM) systems.
• Automation: Automate repetitive tasks like inventory updates and order processing to
reduce manual effort.
• Customer-Centric Approach: Improve the customer experience with real-time product
availability and faster order fulfillment.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Step 2
• Current State Assessment:
• No Software Implementation
• Manual Processing of Data
• No centralized view of data
• No way to handle business growth
• Target State
• Integration
• Automation
• Customer Centric Approach
• Gap Analysis
• Full Fledged Automation
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,
Vello re.
Step 3: Design and EA Implementation
Phase
Business Architecture The team maps out key business processes:
Order Processing; Inventory Management; Customer Management
Information Archi tect ure The Team maps out how to handle the e-commerce data:
Centralized System
Customer Data Platform (CDP)

Application Archi tect ure The Team maps out how to handle the design of e-commerce application:
Microservice Architecture; SOA
Event Driven Architecture
Layered Architecture

Technology The Team maps out which technology to use:

Cloud Hosting
Security Implement secure payment gateways, data encryption, and compliance with industry
standards for handling customer data.
Governance The team sets up a governance structure to oversee the implementation of the new
architecture. Thi s includes defining roles and responsibi lities, setting up regul ar progress
reviews, and addressing any issues that arise during implementation.
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Result
• Improved Operational Efficiency: The integration of inventory, order
management, and CRM systems reduced manual work and eliminated errors,
resulting in faster order processing and better stock management.
• Real-Time Data: The centralized ERP system ensured that the website always
displayed up-to-date inventory levels, which improved customer satisfaction
by reducing the number of out-of-stock products.
• Scalability: The cloud infrastructure allowed XYZ Electronics to handle increased
traffic, especially during high-demand periods like holiday sales, without
worrying about downtime or slow performance.
• Better Customer Experience: Automated workflows and personalized customer
data allowed the company to offer quicker service, personalized
recommendations, and faster response times to inquiries.
• Cost Savings: Automation reduced the need for manual intervention in tasks like
order fulfillment and inventory management, saving the company time and
money.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Various Architecture Design pattern
(Refer the table given under architectural styles and architectural
patterns)

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
Model-View-Controller (MVC) Design
Pattern
• The Model-View-Controller (MVC) design pattern is one of the most
widely used software design patterns, especially in web
development.
• It separates an application into three interconnected components:
• Model
• View
• Controller
• This separation of concerns promotes organized code, improves
maintainability, and enhances testability.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
Components of MVC - Model
• The Model represents the application's data, business logic, and the rules
that govern how data can be manipulated or processed.
• It is responsible for handling data-related tasks such as retrieving,
updating, inserting, or deleting data in a database.
• Responsibilities:
• It directly manages the data of the application.
• It responds to requests for information and instructions from the controller.
• It updates the view when data changes.
• Example:
• In an online store, the Model might represent the "Product" data, which includes
attributes like name, price, and quantity. It would also contain methods like
addProduct, updateProduct, or deleteProduct to manipulate the data.
Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Components of MVC - View
• The View is responsible for displaying the data (provided by the Model) to
the user in a presentable way.
• It is the user interface (UI) part of the application.
• Views only display the data and do not perform any business logic or data
manipulation.
• Responsibilities:
• It renders the user interface.
• It listens to changes in the Model and updates the UI when necessary.
• It receives user input but does not process it; instead, it sends the input to the
Controller for handling.
• Example:
• For the online store, the View could be an HTML page that displays the list of
products, their names, prices, and quantities in a user-friendly format.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Components of MVC - Controller
• The Controller serves as the intermediary between the Model and the
View.
• It listens to user input (e.g., clicks, keystrokes), processes it (with the help
of the Model), and updates the View accordingly.
• Responsibilities:
• It receives input from the user via the View.
• It processes the input (often calling methods on the Model).
• It updates the View based on the results of its processing.
• Example:
• In an online store, when a user generates bill, the Controller would process this
action, update the Model to reflect the new cart state, and possibly update the View
to show the updated cart.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
 Flow of Data in MVC
1. User Interaction with View: The user interacts with the
View, such as clicking a button or entering text into a
form.
2. View Receives User Input: The View receives the user
input and forwards it to the Controller.
3. Controller Processes User Input: The Controller receives
the user input from the View. It interprets the input,
performs any necessary operations (such as updating
the Model), and decides how to respond.
4. Controller Updates Model: The Controller updates the
Model based on the user input or application logic.
5. Model Notifies View of Changes: If the Model changes,
it notifies the View.
6. View Requests Data from Model: The View requests
data from the Model to update its display.
7. Controller Updates View: The Controller updates the
View based on the changes in the Model or in response
to user input.
8. View Renders Updated UI: The View renders the
updated UI based on the changes made by the
Controller. Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,
Vello re.
Example of the MVC Design Pattern

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
 MODEL Controller

VIEW

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
When to Use the MVC Design Pattern
• Complex Applications: Use MVC for apps with many features and
user interactions, like e-commerce sites. It helps organize code and
manage complexity.
• Frequent UI Changes: If the UI needs regular updates, MVC allows
changes to the View without affecting the underlying logic.
• Reusability of Components: If you want to reuse parts of your app in
other projects, MVC’s modular structure makes this easier.
• Testing Requirements: MVC supports thorough testing, allowing you
to test each component separately for better quality control.

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.
When Not to Use the MVC Design Pattern
• Simple Applications: For small apps with limited functionality, MVC
can add unnecessary complexity. A simpler approach may be better.
• Real-Time Applications: MVC may not work well for apps that require
immediate updates, like online games or chat apps.
• Tightly Coupled UI and Logic: If the UI and business logic are closely
linked, MVC might complicate things further.
• Limited Resources: For small teams or those unfamiliar with MVC,
simpler designs can lead to faster development and fewer issues.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT,

Vello re.
Software Architecture Standards
• Standards in software architecture refer to predefined guidelines,
principles, and best practices that ensure consistent, maintainable,
and high-quality designs across systems.
• These standards often cover areas like design patterns, coding
conventions, security, scalability, performance, and integration
methods.

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
 Standard Description
Architecture Standard IEEE 1471-2000 (now ISO/IEC 42010:2011):
Coding Standards • PSR (PHP Standards Recommendations) for PHP development.
• PEP 8 for Python.
• Google Java Style Guide for Java.
Security Standards OWASP (Open Web Application Security Project)
ISO/IEC 27001
OAuth 2.0
Quality Assurance and Testing Standards Test-Driven Development (TDD)
Continuous Integration and Continuous Delivery (CI/CD) standards.
ISO/IEC 25010 for software product quality requirements.
Interoperability Standards REST, SOAP
JSON, XML
Documentat ion Standards UML (Unified Modeling Language)
API documentation standards (e.g., Swagger/OpenAPI for REST APIs).

Dr.Swetha.N.G., Assistant Pro fes sor Senior, SCOPE, VIT, Vello re.
Benefits of Using Standards in Software
Architecture
• Improved Code Quality and Consistency
• Easier Maintenance and Scalability
• Increased Productivity
• Better Communication and Collaboration
• Enhanced Testability
• Interoperability and Integration
• Security and Compliance
• Easier Onboarding and Knowledge Transfer
• Better Performance Optimization
• Long-Term Viability and Sustainability

Dr.Swetha.N.G., Assi stant Pro fes sor Senior, SCOPE, VIT, Vello re.