RGPV SOFTWARE ARCHITECTURE (CS 701) - COMPREHENSIVE

EXAM NOTES
Table of Contents
Complete Guide for 7th Semester | RGPV Bhopal

TABLE OF CONTENTS
UNIT 1: FUNDAMENTALS OF SOFTWARE ARCHITECTURE
What is Software Architecture?

Evolution of Software Architecture

Architecture Business Cycle (ABC)
Software Components and Connectors

What Makes a "Good" Architecture?

Quality Attributes vs Functional Requirements
Architectural Patterns, Reference Models & Reference Architectures
UNIT 2: ARCHITECTURAL STYLES & PATTERNS
Major Architectural Styles

Design Patterns
UNIT 3: IMPLEMENTATION TECHNOLOGIES
Middleware & Frameworks
Web Application Frameworks
UNIT 4: ARCHITECTURE ANALYSIS & DESIGN
Quality Attributes
Quality Attribute Scenarios

Tactics for Achieving Qualities

Architecture Design Methods
Architecture Evaluation Methods
UNIT 5: ARCHITECTURE DOCUMENTATION

Documentation Package Contents

Views and Viewpoints
Reconstruction of Software Architecture
IMPORTANT EXAM QUESTIONS (PREVIOUS YEAR)
Unit 1 Questions
Unit 2 Questions
Unit 3 Questions
Unit 4 Questions
Unit 5 Questions
KEY CONCEPTS & QUICK REFERENCE
Important Definitions
Critical Design Decisions

Common Mistakes in Architecture

Best Practices
EXAM TIPS & STRATEGY
 2-3 Days Before Exam

During Exam
Scoring Strategy
High Priority Topics (Must Study)

Complete Guide for 7th Semester | RGPV Bhopal

TABLE OF CONTENTS
Unit 1: Fundamentals of Software Architecture
Unit 2: Architectural Styles and Patterns

Unit 3: Implementation Technologies

Unit 4: Architecture Analysis & Design Methods
Unit 5: Architecture Documentation

Important Exam Questions (Previous Year)

Quick Reference & Key Concepts

UNIT 1: FUNDAMENTALS OF SOFTWARE ARCHITECTURE

What is Software Architecture?
Software Architecture is the high-level structure of a software system, providing:

Blueprint for software development

Structure of implementation units (modules, components)
Relationships and communication between components
Foundation for achieving quality attributes

Framework for system design and development

IEEE Definition:
"The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design
and evolution over time."

Evolution of Software Architecture

Pre-Architecture Era:
Code-centric approach

No formal design methodology

Ad-hoc system development
High maintenance costs

Modern Architecture-Based Development:

Systematic design approach
Quality-driven development

Risk mitigation
Reduced development and maintenance costs

Improved communication among stakeholders

Architecture Business Cycle (ABC)
The ABC describes how architecture influences and is influenced by business and organizational factors.

Influences on Architecture:
1. Stakeholders:

Customer (business goals)

End users (usability, functionality)

Developers (technical feasibility)

Project managers (time, cost, resources)

Maintainers (modifiability, reliability)
Marketing teams (time to market, cost)

Each stakeholder has different concerns and quality attribute priorities.

2. Developing Organization:

Available skills and expertise

Development budget and schedule
Team structure and size
Previous architectural experiences
Organizational constraints

3. Architect's Background:

Previous experience with architectural patterns

Education and training
Success/failure with particular approaches
Technical expertise
Innovation desires

4. Technical Environment:

Available technologies and tools

Industry standards and practices
Platform constraints

Middleware availability
Development methodologies prevalent in the industry

ABC Feedback Loop:

Architecture → Developing Organization Structure
↓
Organization influences Architecture decisions
↓
System implementation from Architecture
↓
Business success/failure influences future architectures
Software Components and Connectors

Components:
Definition: Units of implementation with encapsulated functionality

Examples: Modules, objects, processes, services, libraries

Responsibilities: Clearly defined functional units

Interfaces: Well-defined entry/exit points

Interactions: Communication with other components through connectors

Connectors:
Definition: Mechanisms of communication and coordination between components
Types:

Procedure call (synchronous)

Asynchronous message passing

Shared data/memory
Remote Procedure Call (RPC)
Publish-Subscribe
Service invocation (SOAP/REST)

Example: Multi-tier Application

Components: UI Layer, Business Logic Layer, Database Layer
Connectors: HTTP requests, SQL queries, API calls

What Makes a "Good" Architecture?

Process Recommendations:
1. Single Architect Leadership: Architecture should be created by one architect or small team with identified leader
2. Clear Requirements: Functional requirements and prioritized quality attributes must be documented

3. Good Documentation: Static and dynamic views using agreed-on notation

4. Stakeholder Review: Architecture circulated to stakeholders for active review
5. Formal Evaluation: Analyzed for quantitative measures before implementation

6. Incremental Implementation: Supports creation of skeletal system for early validation

7. Communication: Clear communication of architectural decisions and rationale

Product/Structural Recommendations:
1. Modularity: Logically partitioned into elements
2. Distinct Views: Representation of data, architecture, interface, components should be distinct
3. Recognizable Patterns: Uses established architectural styles and design patterns
4. Appropriate Data Structures: Well-designed data models
5. Independent Components: Components show independent functional characteristics
6. Reduced Complexity: Interfaces reduce complexity of component connections
7. Traceability: Repeatable methods for design and documentation
8. Clear Notation: Uses effective notation for communication
Quality Attributes vs Functional Requirements

Aspect Functional Requirements Quality Attributes

Definition "What the system should do" "How well the system performs"

Examples User login, data retrieval Performance, security, reliability

Priority Always high Varies by system type

Architecture Impact Less critical Highly critical - shapes architecture

Testing Easy to test Requires special evaluation methods

Changes Can be added easily Difficult to retrofit into system

Architectural Patterns, Reference Models & Reference Architectures

Architectural Patterns (Styles)

Definition: A description of element and relation types together with a set of constraints on how they may be used.

Characteristics of a Pattern:

Set of element types (data repositories, processors)

Topological layout showing interrelationships
Set of semantic constraints
Set of interaction mechanisms

Examples: Client-Server, Pipe-and-Filter, Layered, Event-Driven, Microservices

Reference Models
Definition: A division of functionality together with data flows between the pieces; a standard decomposition of a known problem.

Characteristics:

Problem-domain focused

Describes how to divide problem space

Technology independent
Shows functional units and their relationships

Example: ISO/OSI Network Model (7 layers)

Reference Architecture
Definition: A reference model mapped onto software elements (components) that cooperatively implement the functionality and data
flows.

Relationship:

Reference Model = "What" (functional decomposition)

Reference Architecture = "How" (implementation mapping)

Example:

Model: Data → Process → Display

Architecture: Database Component → Business Logic Component → UI Component
Architectural Views
View: A representation of a coherent set of architectural elements as written by and read by system stakeholders.

Structure: The set of elements itself as they exist in software or hardware.

Three Main Types of Structures:

1. Module Structures:
Elements: Modules (units of implementation)

Focus: Code-based decomposition

Relationships: Containment, generalization, dependency
Notation: Dependency diagrams, class hierarchies

Use: Development team planning, implementation assignment

2. Component-and-Connector Structures:
Elements: Components (runtime units), Connectors (communication)

Focus: Runtime behavior and interaction

Relationships: Invocation, data flow, synchronization
Notation: State machines, sequence diagrams
Use: Understanding system behavior, performance analysis
3. Allocation Structures:

Elements: Software elements to non-software elements (hardware, teams, files)

Focus: Mapping software to deployment environment
Relationships: Deployment, assignment, work allocation
Use: Deployment planning, team organization

UNIT 2: ARCHITECTURAL STYLES & PATTERNS

Major Architectural Styles

1. Layered Architecture (N-tier)

Structure:

System divided into layers

Each layer has specific responsibility
Communication primarily between adjacent layers
Typically 3-4 layers

Common Layers:

1. Presentation Layer: User Interface, Web Interface

2. Business Logic Layer: Core application logic, business rules

3. Persistence Layer: Database access, data management

4. Data Layer: Actual database (sometimes integrated with Persistence)

Advantages:

Easy to understand and organize

Good for rapid development

Clear separation of concerns

Easy to test individual layers

Suitable for small to medium projects
Disadvantages:

Can become monolithic

Performance overhead from layer hopping

Not suitable for distributed systems

Tight coupling between layers possible

Scalability limitations
Best For: Business applications, traditional web applications, CRUD operations

2. Pipe-and-Filter Architecture
Structure:

Data flows through series of independent components (filters)

Connectors (pipes) transmit data between filters
Each filter performs specific transformation

Unidirectional data flow

Components:

Filters: Independent processors that transform input to output

Pipes: Channels connecting filters, buffering data
Source: Initial data producer

Sink: Final data consumer

Data Flow:
Input → Filter1 → Pipe → Filter2 → Pipe → Filter3 → Output

Advantages:

High reusability of filters

Easy to understand

Parallel processing possible

Testable components
Supports stream processing
Disadvantages:

Not suitable for interactive systems

Difficult for request-response patterns

Data transformation overhead

Complex error handling

Not good for systems requiring feedback loops

Best For: Data processing systems, ETL pipelines, compiler construction, text processing

Example: Unix command pipeline

cat data.txt | grep "pattern" | sort | uniq

3. Data-Centered Architecture
Structure:

Central data repository (database, file system)

Multiple components access and modify central data

Components are "clients" of the data store

All communication through shared data
Types:

a) Traditional Database-Centric:

SQL database at center

Multiple applications access same database

ACID properties maintained

b) Blackboard Architecture:

Shared data store (blackboard)

Multiple knowledge sources contribute
Control mechanism coordinates components
Used in AI, pattern recognition

Advantages:

Centralized data management

Consistency and ACID properties
Easy data sharing between components
Backup and recovery simplified

Disadvantages:

Central database is single point of failure

Performance bottleneck
Scalability issues
Data coupling between components
Not suitable for distributed systems

Best For: Database-driven applications, collaborative systems, knowledge management systems

4. Call-and-Return Architecture
Structure:

Components invoke other components synchronously

Caller waits for response
Control flow follows invocation sequence
Hierarchical component organization

Variations:

a) Main Program and Subroutine:

One main program calls subroutines

Subroutines return control to main

Sequential execution

b) Object-Oriented:

Objects communicate via method calls

 Encapsulation and inheritance

Polymorphism for flexibility

c) Client-Server:

Clients request services from servers

Servers provide responses

Network-based communication
Advantages:

Easy to understand control flow

Efficient for sequential processing

Reduced complexity for small systems
Good for standard business applications

Disadvantages:

Tight coupling between components

Difficult for asynchronous operations

Not suitable for highly interactive systems
Limited scalability
Synchronous calls can create bottlenecks

Best For: Traditional business applications, simple procedural systems, object-oriented systems

5. Event-Driven Architecture (Implicit Invocation)

Structure:

Components don't directly invoke each other

Components announce events
Other components listen for events

Asynchronous communication through event bus/mediator

Types:

a) Event Mediator:

Central event manager/mediator

Receives events and routes to appropriate handlers

Coordinates component interaction
b) Event Broker:

Distributed event routing

Brokers coordinate event propagation

No central point of control
Advantages:

Loose coupling between components

Highly responsive and reactive

Asynchronous processing

Scalable to many components

Easy to add new event handlers

Good for real-time systems

Disadvantages:
 Complex event flow to understand and debug

Performance overhead from event processing

Difficult to trace execution
Event routing complexity

Testing challenges

Best For: Real-time systems, stock trading platforms, sensor networks, reactive applications, gaming

6. Microservices Architecture
Structure:

Multiple small, independent services

Each service has specific business capability

Services communicate via APIs (REST, gRPC)
Deployed independently

Data replicated/distributed per service

Characteristics:

Independently Deployable: Each service deployed separately

Organized Around Business Capabilities: Services around business functions
Domain-Driven Design: Services map to business domains

Decentralized Data Management: Each service has its database

Infrastructure Automation: CI/CD pipelines for deployment
Design for Failure: Resilience, circuit breakers, timeouts

Advantages:

Scalability: Each service scales independently

Flexibility: Technologies can vary per service

Fault Isolation: Failure in one service doesn't crash entire system

Continuous Deployment: Independent release cycles
Team Autonomy: Teams can work independently
Technology Diversity: Use best tool for each service

Disadvantages:

Complexity: Distributed system challenges

Testing Difficulty: Integration testing more complex

Operational Complexity: Monitoring, logging, debugging harder

Network Latency: Inter-service communication overhead

Data Consistency: Distributed transactions problematic

Deployment Complexity: Many services to manage

Best For: Large systems, multiple independent teams, scalable platforms, complex business domains

7. Service-Oriented Architecture (SOA)

Structure:

Coarse-grained services (vs microservices' fine-grained)

Services accessible via standard interfaces (SOAP, XML-RPC)
Enterprise service bus (ESB) for communication
Service registry for discovery
Key Concepts:

Service: Coarse-grained business functionality

ESB: Centralized message routing and transformation

Service Registry: Yellow pages for services

Standards-Based: XML, WSDL, SOAP

Advantages:

Business process alignment

Service reusability across applications

Centralized management via ESB

Platform independence

Disadvantages:

ESB can become bottleneck

Complexity of implementation

Standards overhead
Performance concerns
Learning curve

Best For: Enterprise systems, legacy system integration, business process integration

8. Reactive Architecture
Structure:

Event-driven, non-blocking
Responsive to stimuli
Scalable, resilient
Message-driven communication
Key Principles (Reactive Manifesto):

1. Responsive: System responds timely to requests

2. Resilient: System handles failures gracefully
3. Elastic: System scales up/down based on demand

4. Message-Driven: Asynchronous message passing

Advantages:

High responsiveness
Efficient resource utilization
Scalability
Fault tolerance
Non-blocking I/O
Disadvantages:

Complex programming model

Debugging and testing harder
Learning curve for developers
Not suitable for simple applications

Best For: High-traffic systems, real-time processing, IoT applications, streaming systems
9. REST Architecture
Structure:

Resources identified by URIs

Standard HTTP methods (GET, POST, PUT, DELETE)

Stateless communication
Client-Server interaction

Representations of resources

Key Concepts:

Resources: Identified by URIs (e.g., /users/123)

Methods: GET, POST, PUT, DELETE for operations

Stateless: No server-side session state

Representations: JSON/XML representations of resources
Hyperlinks: Links for navigating resources

Advantages:

Scalability via statelessness

Simplicity and ease of use
Web technologies

Easy to cache
Standard interface

Disadvantages:

Not optimal for all use cases

Potential over-fetching/under-fetching
Versioning challenges
Security considerations

Best For: Web APIs, mobile applications, microservices, web services

Design Patterns
Design patterns are reusable solutions to common problems in software design. They provide templates for solving recurring design
problems.

Creational Patterns (Object Creation)

1. Singleton:

Only one instance of class

Global access point
Use: Logging, configuration, database connections
2. Factory:
Create objects without specifying exact classes
Encapsulate object creation
Use: Database drivers, UI components
3. Builder:
Construct complex objects step by step
Separate construction from representation
Use: Document creation, configuration objects
 4. Prototype:

Clone existing objects

Avoid expensive creation
Use: Document copying, object duplication

Structural Patterns (Object Composition)

1. Adapter:
Convert incompatible interfaces

Make incompatible classes work together

Use: Library integration, legacy system adaptation
2. Facade:

Provide simplified interface to complex subsystem

Hide complexity from client
Use: Simplifying large frameworks

3. Proxy:
Placeholder for another object
Control access to real object
Use: Lazy loading, access control, caching
4. Decorator:

Add functionality to objects dynamically

Alternative to subclassing
Use: Adding features without modification

Behavioral Patterns (Object Interaction)

1. Observer:

Notify multiple objects of state changes

Loose coupling between objects
Use: Event handling, MVC, real-time updates
2. Strategy:
Encapsulate interchangeable algorithms
Change algorithm at runtime
Use: Payment methods, sorting algorithms
3. Command:
Encapsulate request as object

Queue, log, undo operations

Use: Undo/redo, macro recording
4. State:
Vary object behavior based on state
Encapsulate state-specific behavior
Use: State machines, workflow systems
UNIT 3: IMPLEMENTATION TECHNOLOGIES
Middleware & Frameworks

Java-based Technologies
1. J2EE (Java 2 Enterprise Edition)

Enterprise Java platform

Components: JSP, Servlets, EJBs
Transaction management
Security features

2. Spring Framework

Dependency injection (IoC container)

Aspect-oriented programming (AOP)

MVC for web applications

Transaction management
Simplified development
3. Hibernate

Object-Relational Mapping (ORM)

Map objects to database tables
HQL (Hibernate Query Language)

Session management
Lazy loading

Middleware
JDBC (Java Database Connectivity)

Database access API

Connection pooling
Prepared statements for security
JNDI (Java Naming and Directory Interface)

Naming service
Service discovery

Resource location
JMS (Java Message Service)

Asynchronous messaging

Point-to-point and publish-subscribe

Message queuing

RMI (Remote Method Invocation)

Call methods on remote objects

Java-to-Java communication
Distributed computing
CORBA (Common Object Request Broker Architecture)

Language-independent distributed computing

 Object Request Broker (ORB)

Cross-platform communication

Architectural Description Languages (ADLs)

Purpose: Formally specify software architecture

Examples:

AADL: Architecture Analysis and Design Language

Wright: Formal ADL for component composition

Darwin: Configuration language
Acme: Architecture description language

UML: Modeling language for architecture

Benefits:

Formal specification

Tool support
Analysis and validation
Documentation

Web Application Frameworks

JSP (JavaServer Pages)

Dynamic web pages
Server-side scripting
HTML with embedded Java

Tag libraries

Servlets
Java programs for web server
Handle HTTP requests
MVC controllers

Node.js
JavaScript runtime

Server-side JavaScript
Event-driven, non-blocking I/O

NPM package ecosystem

Angular.js
Frontend JavaScript framework

MVC/MVVM architecture
Two-way data binding
Component-based
UML in Software Architecture
Role of UML:

Visualize architecture
Communicate design decisions

Component diagrams for structure

Deployment diagrams for distribution

Sequence diagrams for interactions

State machines for behavior

UNIT 4: ARCHITECTURE ANALYSIS & DESIGN

Quality Attributes
Definition: Non-functional requirements that describe "how well" the system performs

Common Quality Attributes

Attribute Description Key Concern

Performance Speed of system response Latency, throughput

Reliability Probability of failure-free operation MTBF, fault tolerance

Security Protection from unauthorized access Authentication, encryption

Usability Ease of use User interface, learning curve

Modifiability Ease of changing functionality Maintainability, extensibility

Testability Ease of testing the system Test coverage, debugging

Availability System uptime Fault detection, recovery

Scalability Ability to handle growth Horizontal/vertical scaling

Interoperability Ability to work with other systems APIs, standards compliance

FURPS Quality Model

Functionality: Features and capabilities
Usability: User interface and user experience
Reliability: Frequency and severity of failures

Performance: Processing speed, response time

Supportability: Extensibility, adaptability, serviceability

Quality Attribute Scenarios

Format: Six-part scenario for quality attribute requirement

1. Source of Stimulus: Entity generating stimulus (user, system, attacker)

2. Stimulus: Condition or event that needs response

3. Environment: Conditions under which stimulus occurs

4. Artifact: System component or entire system affected

5. Response: Activity undertaken by system

6. Response Measure: Measurable way to determine if requirement met
Example: Performance Scenario
> Source: End user
> Stimulus: Places order on e-commerce website
> Environment: Peak traffic during holiday season
> Artifact: Order processing system
> Response: System processes and confirms order
> Response Measure: Response time < 2 seconds with system at 80% capacity

Example: Security Scenario

> Source: Attacker
> Stimulus: Attempts to inject SQL command
> Environment: During normal system operation
> Artifact: Database access layer
> Response: System rejects injection, logs incident, alerts admin
> Response Measure: Attack prevented, logged, 0 data accessed

Tactics for Achieving Qualities

Tactic: A design decision that influences the control of quality attribute response

Performance Tactics
Caching: Store frequently accessed data
Load Balancing: Distribute requests across servers

Parallel Processing: Process multiple requests concurrently

Compression: Reduce data transfer size
Database Indexing: Faster data retrieval

Modifiability Tactics
Encapsulation: Hide implementation details

Low Coupling: Minimize component dependencies

High Cohesion: Keep related functionality together
Interfaces: Define clear component boundaries
Parameterization: Make behavior configurable

Security Tactics
Authentication: Verify user identity
Authorization: Control access to resources
Encryption: Protect data in transit and rest

Audit Logging: Record security events

Input Validation: Prevent injection attacks

Availability Tactics
Redundancy: Multiple instances for failover

Health Monitoring: Detect failures

Automatic Recovery: Restart failed components

Graceful Degradation: Continue with reduced functionality

Timeouts: Prevent hanging requests
Architecture Design Methods

Attribute-Driven Design (ADD)

Process: Decompose architecture based on quality attributes

Steps:

1. Select Element to Decompose:

Usually starts with entire system
Identify inputs: constraints, functional requirements, quality scenarios
2. Choose Architectural Drivers:

Select most important quality attributes

Identify functional requirements driving design
3. Select Architectural Pattern:

Choose pattern satisfying architectural drivers

Use tactics to achieve qualities

4. Instantiate Modules:
Allocate functionality to modules
Define module responsibilities
Create module structure
5. Define Interfaces:
Specify module interactions

Document APIs
Define communication protocols
6. Verify and Refine:
Check scenarios against design
Refine quality requirements for child modules
Repeat for each module

Output: Module structure, quality scenarios, architectural decisions

Architecture Evaluation Methods

ATAM (Architecture Tradeoff Analysis Method)

Purpose: Evaluate architecture against quality goals and identify tradeoffs

Participants:

1. Evaluation Team: External evaluators (3-5 people)

2. Project Decision Makers: Project manager, customer, stakeholders

3. Architecture Stakeholders: Developers, testers, maintainers, users
Phases:

Phase 1: Partnership & Preparation

Define evaluation goals

Identify stakeholders
Schedule resources

Prepare evaluation plan

Phase 2: Evaluation - Presentation
 Architecture team presents architecture

Stakeholders ask questions

Evaluation team understands architecture
Phase 3: Evaluation - Investigation

Identify architectural patterns

Document quality scenarios

Analyze scenarios against architecture

Identify risks and tradeoffs

Phase 4: Testing - Scenario Brainstorming

Stakeholders generate additional scenarios

Prioritize scenarios

Refine quality requirements

Phase 5: Reporting

Document findings
Identify risks and non-risks
Identify sensitivity and tradeoff points
Recommend improvements

Output:

Architectural risks
Sensitivity points (design decisions affecting qualities)
Tradeoff points (decisions affecting multiple qualities)

CBAM (Cost Benefit Analysis Method)

Purpose: Analyze business value vs. cost of architectural decisions

Steps:

1. Elicit business goals

2. Identify architectural approaches
3. Determine quality attribute impacts

4. Estimate costs of each approach

5. Calculate return on investment (ROI)
6. Rank approaches by ROI

UNIT 5: ARCHITECTURE DOCUMENTATION

Documentation Package Contents

1. Primary Presentation
Overview of architectural element
Key responsibilities

Important relationships
Visual representation (diagram)
2. Element Catalog
Detailed description of each element
Properties and attributes

Responsibilities
Interfaces and APIs

Data types

3. Context Diagram
Shows element within context
External systems and dependencies

Input and output

System boundaries

4. Variability Guide
Design decisions not yet made
Options and alternatives
Evolution possibilities
Parameterization

5. Architecture Background
Design rationale
Design decisions and tradeoffs
Quality attribute scenarios
Constraints and assumptions

6. Glossary
Terminology definitions
Domain-specific terms
Ambiguous words clarified

7. Other Information
Related documentation
External references

Change history
Version information

Views and Viewpoints

Four+One View Model

1. Logical View: Functional decomposition (modules, classes)

2. Process View: Runtime behavior (processes, threads)

3. Development View: Code organization (files, directories)

4. Physical View: Hardware deployment (processors, networks)

5. Scenario View: Use cases showing all views in action
Reconstruction of Software Architecture
Purpose: Document and understand existing systems

Activities:

1. Information Extraction:

Source code analysis

Documentation review
Interview stakeholders
Configuration analysis
2. Database Construction:

Convert information to standard form

Store in queryable database
Organize relationships

3. View Fusion:

Combine information from multiple sources

Create coherent architecture representation
Resolve conflicts
4. Reconstruction:
Build abstractions from data
Generate architectural representations
Document architecture

IMPORTANT EXAM QUESTIONS (PREVIOUS YEAR)

Unit 1 Questions
Q1. What is Software Architecture? Explain its importance in software development.

Definition and characteristics

Key components: modules, connectors

Benefits: early decision-making, risk reduction, communication

Impact on development process

Q2. Explain Architecture Business Cycle (ABC) in detail.

Influences on architecture (stakeholders, organization, architect, environment)

Feedback loops
How architecture affects system and organization

Business impact on architecture decisions

Q3. Distinguish between reference model, reference architecture, and architectural patterns.

Reference model: Problem decomposition

Reference architecture: Implementation mapping
Patterns: Recurring solutions
Relationships and examples

Q4. What are the three types of architectural structures? Explain with examples.

Module structures (decomposition, classes, uses)

Component-and-connector (client-server, concurrency)
Allocation (deployment, work assignment)
Q5. What makes a "good" architecture? Discuss process and product recommendations.

Unit 2 Questions
Q1. Compare and contrast Layered vs. Pipe-and-Filter architectural styles.

Structure and communication patterns

Advantages and disadvantages of each

Best use cases

Example systems

Q2. Explain Microservices Architecture with its characteristics, advantages, and disadvantages.

Structure and principles

Independent deployability
Scaling and fault isolation
Operational complexity

When to use

Q3. What is Event-Driven Architecture? Explain event mediator and event broker approaches.

Components and interaction

Event flow
Advantages and challenges
Real-world examples

Q4. Explain REST architectural style. How does it differ from SOAP/SOA?

RESTful principles
Resource-oriented approach
HTTP methods
Statelessness
Comparison with other approaches

Q5. Describe Design Patterns. Categorize and explain 3 patterns from each category.

Creational, Structural, Behavioral

Purpose and use of each pattern
Real-world examples

When to use each pattern

Unit 3 Questions
Q1. Explain J2EE architecture and its components (JSP, Servlets, EJBs).

Layered architecture

Each component's role

Communication between components

Q2. What is Hibernate ORM? How does it map objects to databases?

Object-relational impedance mismatch

HQL and mapping files

Session management
Advantages over JDBC
Q3. Explain middleware technologies: JDBC, JNDI, JMS, RMI, CORBA.

Purpose of each
 How they enable distributed computing

When to use each

Q4. What role does UML play in software architecture documentation?

Notation for architecture

Diagram types for architecture

Tool support
Limitations

Unit 4 Questions
Q1. Define quality attributes and explain FURPS model.

Functionality, Usability, Reliability, Performance, Supportability

Examples of each
How they guide architecture

Q2. Explain quality attribute scenarios with 6-part template. Give examples.

Source, stimulus, environment, artifact, response, response measure

Performance scenario example
Security scenario example
How to write measurable scenarios

Q3. What are tactics? How do they help achieve quality attributes?

Definition and purpose

Tactics for different qualities

How to apply tactics
Tradeoffs between tactics
Q4. Describe Attribute-Driven Design (ADD) method.

Process steps
Inputs and outputs

How it selects patterns and tactics

Comparison with other design methods
Q5. Explain ATAM evaluation method. What are its phases and outputs?

Participants and their roles

5 phases
Architectural risks and sensitivity points
When to use ATAM

Q6. What is CBAM? How is it used for architecture decisions?

Cost-benefit analysis

ROI calculation
Business value assessment

Unit 5 Questions
Q1. What should be included in architecture documentation package?

Seven parts of documentation

Purpose of each part
Importance of complete documentation
Q2. Explain 4+1 view model.

Logical, Process, Development, Physical, Scenarios

Purpose of each view

Stakeholders for each view

Q3. How do you reconstruct architecture of existing systems?

Activities: extraction, construction, fusion, reconstruction

Tools and techniques
Challenges and solutions

KEY CONCEPTS & QUICK REFERENCE

Important Definitions

Term Definition

Architecture High-level structure defining components and their relationships

Pattern Reusable solution to recurring design problems

Tactic Design decision influencing quality attribute response

Quality Attribute Non-functional requirement describing "how well" system performs

Stakeholder Person/organization with interest in system

View Representation of architectural elements

Connector Communication mechanism between components

Module Implementation unit with encapsulated functionality

Critical Design Decisions

1. Architectural Style Choice: Foundation for entire architecture
2. Quality Attributes: Drives all other decisions

3. Component Decomposition: How to break system into manageable parts

4. Communication Mechanisms: How components interact

5. Data Management: Centralized vs. distributed data

6. Deployment Strategy: Physical distribution of components

Common Mistakes in Architecture

❌ No clear quality attribute prioritization

❌ Ignoring stakeholder concerns

❌ No documentation
❌ Using inappropriate patterns for problem
❌ Tight coupling between components
❌ No evaluation before implementation
❌ Poor communication of architecture
❌ Not considering scalability early
Best Practices
✓ Identify and prioritize quality attributes early
✓ Involve all stakeholders in design
✓ Use proven patterns and tactics
✓ Document architecture thoroughly
✓ Evaluate architecture formally (ATAM)
✓ Plan for evolution and change
✓ Consider scalability and performance
✓ Build prototypes for high-risk areas
✓ Maintain traceability to requirements
✓ Review and refine iteratively

EXAM TIPS & STRATEGY

2-3 Days Before Exam
✓ Review all 5 units equally
✓ Practice drawing architecture diagrams
✓ Memorize definition of key terms
✓ Compare architectural styles (advantages/disadvantages)
✓ Solve previous year questions
✓ Understand quality attributes and scenarios
✓ Know ADD and ATAM methods thoroughly

During Exam
✓ Read questions carefully - understand what's being asked
✓ Answer with architectural perspective, not just code
✓ Draw diagrams - they score well and help explain
✓ Use examples from real systems
✓ Compare and contrast when asked
✓ Short questions: Breadth over depth
✓ Long questions: Depth with examples

Scoring Strategy
Very Short/MCQ (If any): Quick answers
Short Answer: 2-3 minutes per question

Long Answer: 10-15 minutes with explanation + diagram

High Priority Topics (Must Study)

1. Architectural Business Cycle

2. Architectural styles (Layered, Pipe-and-Filter, Microservices, Event-Driven)

3. Quality attributes and FURPS

4. ADD method

5. ATAM evaluation
6. Documentation views

7. Design patterns (Creational, Structural, Behavioral)

Good Luck with Your Exam! 🎓

Remember: Software Architecture is about making strategic design decisions that enable business goals while achieving quality
attributes. Focus on the "why" behind designs, not just the "how."

Exam Duration: 3 Hours | Total Marks: 70 (typically)

[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
⁂

1. https://www.rgpv.ac.in/UC/frm_download_file.aspx?Filepath=CDN%2FPubContent%2FScheme%2FComputer_Science_100720025532.pdf

2. https://www.rgpvnotes.in/btech/grading-system-old/notes/2022/11/software-architectures-cs-701

3. https://www.rgpv.ac.in/UC/frm_download_file.aspx?Filepath=CDN%2FPubContent%2FScheme%2FComputer_Science_100720025532.pdf

4. https://www.tecnrt.org/docs/cse/materials/SADP.pdf

5. https://www.rgpv.ac.in/campus/CS/Unit-III.pdf

6. https://www.tecnrt.org/docs/cse/materials/SADP.pdf

7. https://www.scribd.com/document/889988502/Software-Architecture-Exam-Notes-CS1-to-CS7

8. https://www.studocu.com/in/document/rajiv-gandhi-proudyogiki-vishwavidyalaya/big-data/cs-701-software-architecture-qb/78800953

9. https://www.scribd.com/document/621219446/Software-Architecture-Styles-and-Pattern
10. http://rgpvcsenotes.blogspot.com/p/7th-semester-notes.html

11. https://www.youtube.com/watch?v=aG6KuU1C_LI

12. https://study.com/academy/practice/quiz-worksheet-architectural-types-in-software-engineering.html