In software architecture, a system is described as a combination of components and connectors. This is known as the Component-and-Connector (C&C) view.

• Components → Perform computation, store data, or provide services
• Connectors → Enable communication and interaction between components

In simple word:
Components = What does the work
Connectors = How components communicate

1. Components

Components are the primary computational units of a system. They can process data, store information, or control system behavior.

Types of Components with Examples

1. Computational Components

• Perform processing or operations
• Example: Payment processing module in an e-commerce system

2. Data Components (Data Stores)

• Store and manage data
• Examples:
  • Database
  • In-memory cache

3. User Interface Components

• Interact with users
• Examples:
  • Login page
  • Dashboard

4. Control Components

• Manage workflow and system execution
• Examples:
  • Event controller
  • Orchestration engine

2. Connectors

Connectors define how components communicate, coordinate, and exchange data.

Types of Connectors with Examples

1. Procedure / Method Call

• One component directly calls another
• Example: Client calling a server API

2. Event / Message Passing

• Communication through asynchronous messages or events
• Example: Message queue (e.g., RabbitMQ)

3. Shared Data / Repository

• Components interact through shared data storage
• Example: Multiple modules accessing the same database

4. Stream / Pipe

• Data flows continuously between components
• Example: Data processing pipelines

5. Broker / Mediator

• Communication via an intermediary component
• Example: Microservices using a service bus

3. Importance of C&C

1. Modularity
   Separates system into smaller parts for easier development and maintenance
2. Reusability
   Components can be reused in different systems
3. Scalability
   Components can be scaled or updated independently
4. Flexibility
   Changes in one component or connector do not affect the entire system
5. Quality Assurance
   Improves system performance, reliability, and maintainability

4. Real-Life Examples

1. Web Application

• Components: Web Server, Database, Login Module
• Connectors: HTTP requests, Database connections

2. E-commerce Platform

• Components: Product Catalog, Shopping Cart, Payment Module
• Connectors: REST API, Message Queue

3. Multimedia System

• Components: Video Decoder, Audio Mixer
• Connectors: Data streams, Event signals

4. Microservices System

• Components: Payment Service, User Service
• Connectors: REST API, gRPC, Message Broker

5. Visual Representation (Example)

Explanation:

• Components:
  User Interface, Web Server, Database, Payment Module
• Connectors:
  HTTP, Database Connection, REST API

This diagram shows how components perform tasks and connectors enable communication.

6. Key Considerations in Designing C&C

1. Coupling & Cohesion
   • High cohesion (focused components)
   • Low coupling (minimal dependency)
2. Performance
   • Connectors should not become bottlenecks
3. Reliability
   • Should handle failures effectively
4. Scalability
   • Components should scale independently
5. Security
   • Connectors may require:
     • Authentication
     • Encryption
     • Access control

The Architecture Business Cycle (ABC) was introduced by Mary Shaw.

Meaning:
It shows the relationship between business goals and software architecture, forming a continuous cycle.

1. Components of Architecture Business Cycle

 a. Business Goals and Objectives

• High-level organizational goals
• Drives software development

Example:
Increase online sales by 30% in 1 year

 b. Technical Environment

• Existing infrastructure and technologies
• Includes hardware, software, networks

Example:
AWS cloud, Java backend

c. Architectural Requirements

Derived from business goals

Types:

• Functional Requirements:
  • What system should do
  • Example: Handle 10,000 users
• Non-Functional Requirements:
  • Quality attributes
  • Example: 99.9% uptime, fast checkout

d. Architectural Design

• System structure based on requirements & constraints

Example:

• Microservices architecture
• Load balancers
• CDN

e. Architecture Influence

• Architecture impacts business & system

Example:

• Faster feature releases
• Better performance
• Increased sales

2.  How the Cycle Works

 Step-by-Step Flow:

1. Business Goals → Requirements
   • Goals define system needs
2. Technical Environment → Design
   • Existing technology shapes design
3. Design → Influence
   • Architecture affects performance & business
4. Feedback → Business Goals
   • New capabilities create new goals

This makes it a continuous cycle

3. Real-Life Example (E-Commerce)

 Scenario:

• Business Goal:
  Increase online sales by 30%
• Technical Environment:
  Java, AWS, MySQL
• Requirements:
  • 10,000 concurrent users
  • 99.9% uptime
  • Fast checkout

 Architectural Design:

• Microservices
• Load balancers
• CDN

Architecture Influence:

• Faster deployment
• Better user experience
• Increased sales
• Mobile app support

A Software Architectural Pattern is a high-level reusable solution that defines how a software system is structured.

Simple Meaning:
It is like a blueprint that shows how the entire system (components + communication) should be organized.

 Key Characteristics of Architectural Patterns

 1. High-Level System Guidance

• Provides overall structure (not code-level details)
• Answers:
  • How modules communicate
  • Where data is processed
  • How system scales

2. Reusable Solutions

• Can be used across multiple projects
• Example: MVC used in many web apps

3. Solve Common Problems

Helps solve:

• Scalability
• Performance
• Maintainability
• Modularity

4. Define Components + Connectors

• Identifies:
  • Components
  • Responsibilities
  • Interactions

5. Improve Quality Attributes

Enhances:

• Performance
• Reliability
• Security
• Scalability
• Maintainability

 Importance of Architectural Patterns

Architectural patterns ensure that a system is:

a)  Well-structured
b)  Easy to maintain
 c) Scalable
 d) Flexible
 e) Efficient

 Helps avoid reinventing solutions and follow best practices

 Major Architectural Patterns

1. Layered Architecture (N-Tier)

 Structure:

1. Presentation Layer (UI)
2. Business Logic Layer
3. Data Access Layer
4. Database Layer

 Working:

• Request: Top → Bottom
• Response: Bottom → Top

 Example:

Browser → API → Service → Database

 Advantages:

• Easy maintenance
• Clear separation
• Easy testing

 Used In:

Banking systems, enterprise apps

2. Client–Server Architecture

 Structure:

• Client → Requests
• Server → Responds

 Example:

Browser → Web Server

 Advantages:

• Centralized control
• Easy updates

 Used In:

Web apps, email, games

3. Microservices Architecture

 Description:

• System divided into small independent services

 Example:

• Payment Service
• Product Service
• Cart Service

 Advantages:

• High scalability
• Fast deployment
• Independent development

 Used In:

Netflix, Amazon, Uber

4. Event-Driven Architecture

 Description:

• Components communicate via events

 Example:

Order Created → Payment + Notification triggered

 Advantages:

• Real-time processing
• Loose coupling
• High responsiveness

 Used In:

IoT, trading systems

5. Pipe and Filter Architecture

 Description:

• Data flows through stages (filters)

 Example:

Compiler → Lexer → Parser → Optimizer

 Advantages:

• Parallel processing
• Reusability

 Used In:

Data processing, compilers

6. Model–View–Controller (MVC)

 Components:

• Model → Data
• View → UI
• Controller → Logic

 Working:

User → View → Controller → Model

 Advantages:

• Separation of concerns
• Easy maintenance

 Used In:

Web frameworks (Django, Rails)

A Reference Model is a conceptual framework that defines the basic elements, functions, and relationships within a specific domain.

It provides a generalized and abstract view of how a system should be structured, without including implementation details.

In simple terms:
A Reference Model is a high-level blueprint that explains:

• What components a system should have
• How those components are related

It does not describe how to build the system.

Key Characteristics of a Reference Model

 a. Abstract

• Does not include technologies or implementation details
• Focuses only on concepts

 b. Generalized Structure

• Defines common components and ideas used across systems

 c. Domain-Focused

• Designed for a specific domain such as:
  • Networking
  • Databases
  • Distributed systems

 d. Guides System Design

• Serves as a foundation for:
  • Reference Architecture
  • System Architecture

e.  Explains Relationships

• Describes how components interact conceptually
• Does not define actual implementation

Why Do We Need Reference Models?

1. Standardization

• Ensures uniform system design across organizations

2. Common Understanding

• Provides a shared vocabulary for teams

3. Simplifies Communication

• Makes it easier to discuss requirements with stakeholders

4. Reusability

• Concepts can be reused across multiple systems

5. Foundation for Architecture

• Flow:

   

  Reference Model → Reference Architecture → System Architecture

   

Examples of Reference Models

1. OSI Model (Open Systems Interconnection)

Layers:

1. Physical
2. Data Link
3. Network
4. Transport
5. Session
6. Presentation
7. Application

Purpose:

• Defines how data travels across a network
• Provides a standard communication structure

Why it is a Reference Model:

• Describes responsibilities of each layer
• Does not specify implementation

2. TCP/IP Model

Layers:

• Network Interface
• Internet
• Transport
• Application

Purpose:

• Defines core networking functions
• Forms the basis of internet communication

3. RM-ODP (Reference Model for Open Distributed Processing)

Views:

• Enterprise View
• Information View
• Computational View
• Engineering View
• Technology View

Purpose:

• Helps design large distributed systems
• Defines roles, interactions, and system distribution

4. Data Reference Models

Example: Data Reference Model (DRM)

Defines:

• Data types
• Relationships
• Data formats
• Metadata standards

5. Cloud Reference Models

Example: NIST Cloud Computing Reference Model

Defines:

• SaaS (Software as a Service)
• PaaS (Platform as a Service)
• IaaS (Infrastructure as a Service)
• Cloud actors and roles

Reference Model vs Reference Architecture

Real-Life Example: E-Commerce Reference Model

A Reference Model for an e-commerce system defines key conceptual areas:

• Product Management
• Order Management
• Customer Management
• Payment Processing
• Inventory Management
• Shipping

 It does NOT define:

• Database technology
• Programming language
• UI framework

 These decisions are made later in:

• Reference Architecture
• System Design