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

What is a Software Architecture Framework?

A software architecture framework is a structured set of principles, practices, and guidelines used to design and organize software systems.

Simple Meaning:
It acts like a blueprint for building software systems.

1. 4+1 View Model

Developer: Philippe Kruchten
Purpose: Describe complex systems from multiple perspectives for different stakeholders.

 Views:

1. Logical View

• Focus: Functional requirements
• Contains: Classes, objects, relationships
• Stakeholders: Developers, Designers
• Example: Product Catalog, Shopping Cart modules

2. Development View

• Focus: Static structure of code
• Contains: Modules, packages, source code
• Stakeholders: Software engineers
• Example: Backend service modules, repositories

3. Process View

• Focus: Runtime behavior & concurrency
• Contains: Threads, processes, communication
• Stakeholders: Developers, System integrators
• Example: Asynchronous order processing

4. Physical View

• Focus: Deployment & hardware
• Contains: Servers, nodes, network
• Stakeholders: System admins, Operations
• Example: Web server + database deployment

5. Scenarios (Use Case View)

• Focus: Real-world system behavior
• Purpose: Connects all views
• Example: User places an order

 Importance:

• Simplifies complex systems
• Improves communication
• Provides stakeholder-specific views

2. Model-Driven Architecture (MDA)

Developer: OMG (Object Management Group)
Purpose: Platform-independent design & automatic code generation

 Models:

1. CIM (Computation Independent Model)

• Focus on business processes & requirements
• Example: Order processing workflow

2. PIM (Platform Independent Model)

• System design without technology details
• Example: UML diagrams

3. PSM (Platform Specific Model)

• Converts PIM into specific technology
• Example: Java Spring Boot code

 Importance:

• Promotes reuse
• Reduces platform dependency
• Supports automation

3. Zachman Framework

Developer: John Zachman
Purpose: Organizes enterprise architecture

 Structure:

• Rows (Stakeholders):
  Planner, Owner, Designer, Builder, Subcontractor, Operations
• Columns (Aspects):
  Data, Function, Network, People, Time, Motivation

 Importance:

• Handles complex systems
• Supports decision-making
• Covers all perspectives

 Example:

• Planner → Defines goals
• Designer → Creates system models

4. TOGAF (The Open Group Architecture Framework)

Purpose: Enterprise architecture planning & governance

 Core: ADM (Architecture Development Method)

Phases:

1. Architecture Vision
2. Business Architecture
3. Information Systems Architecture
4. Technology Architecture
5. Opportunities & Solutions
6. Migration Planning
7. Implementation Governance

 Importance:

• Used in large organizations
• Aligns IT with business goals
• Provides structured approach

5. IEEE 1471 / ISO/IEC/IEEE 42010

Purpose: Standard for architecture documentation

 Components:

• Stakeholders
• Views & viewpoints
• Architecture description

 Importance:

• Standardizes documentation
• Improves communication
• Ensures stakeholder concerns are addressed

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