Process-Control and Architecture Fundamentals

Software Architecture

• Software architecture is the fundamental organization of a system
• It encompasses components, their relationships, and the principles guiding design and evolution.
• It describes the elements of a system, their interactions, and the guiding principles.

Software Development Activities

• The goal of software design is to craft a model aligning with client requirements and facilitating successful implementation.
• Software product/system success heavily depends on strong architecture design.

Software Architect Responsibilities

• Software architects and designers translate system requirements into architectural designs.
• Employ diverse architectural design strategies.
• Simplify complex application domains.
• Resolve software architecture complexities.

Importance of Software Architecture Design

• Effective design minimizes software development risks.
• Facilitates orderly team coordination.
• Enables system traceability for implementation and testing.
• Enhances software quality attributes.

Software Architecture Role in SDLC

• Software architecture plays a crucial role in the software development life cycle (SDLC).
• The Software Requirements Specification (SRS) serves as input for software design.
• Software Design Description (SDD) reports software architecture or high-level design, combined with detailed system design.

Architectural Styles (Architecture Patterns)

• Architectural styles abstract common properties of similar designs.
• Define rules, constraints, and patterns for system structure.
• Govern overall constituent element types, runtime interaction (flow control and data transfer).
• Four key components: Elements, Connectors, Attributes, and Constraints.

Software Architect's Tasks

• Perform system static partitioning
• Decompose the system into sub-systems and define communications.
• Employ replaceable sub-systems, facilitated by loose coupling between elements.
• Establish dynamic control relationships between system subsystems.
• Consider and evaluate alternative architectures.

Common Software Architecture Patterns

• Monolithic, Data flow, Data-Centered, Object-oriented, Component-Based, Service-Oriented, Hierarchical, Virtual Machine, Layered, Pipes and Filters, and Broker Architecture

Monolithic Architecture

• Single package incorporating all program components.
• Efficient communication between components (local).
• Suited for small, straightforward software systems.

Data Flow Architecture

• System viewed as successive data transformations through processing components.
• Output of preprocessor serves as input for the postprocessor.
• Common types include Batch Sequential Architecture (BSA), Pipes and Filters, and Process-Control.

Batch Sequential Architecture (BSA)

• Traditional data processing model (1950s-1970s).
• Sub-systems execute sequentially, dependent on preceding computations.

Pipes and Filters Architecture

• Improved form of sequential batch architecture.
• System divided into data source, pipes, filters, and data sink components.

Data Transfer Types

• Push-only (write-only): data source pushes data to downstream elements.
• Pull-only (read-only): data sink pulls data from upstream elements.
• Push-pull (read-write): filters read data from upstream and write transformed data to downstream.

Process Control Architecture

• Suitable for embedded systems with process control variables.
• System decomposed into sub-systems with defined connections.
• Elements such as controller unit and executor processing unit manipulate variables.

Data Centered Architecture (DCA)

• Separates data store from independent software components (agents).
• Centralized data store supports sharing among agents.
• Communication (invocation) between data and agents can be explicit or implicit.

Repository

• Data store (passive) managed by active software agents (components).
• Agents interact interactively or via batch transactions.
• Suitable for large, complex systems with numerous agents.

Blackboard Architecture

• Architectural style resembling a classroom’s blackboard.
• Software units (agents) work in parallel and independently.
• Blackboard (active data store) holds data and hypotheses, agents contain domain knowledge.
• Controller unit initiates and manages knowledge sources.

Object Oriented Architecture

• System comprises interconnected objects with attributes and methods.
• Objects communicate through message exchanges to complete tasks.
• Features like abstraction, inheritance, and encapsulation streamline software design.

Component-Based Architecture

• System subdivided into independent components handling subproblems, deployed separately.
• Components feature specific functionalities, are reusable, and communicate through interactions.

Hierarchical Architecture

• System organized in a hierarchy of modules (sub-systems).
• Lower-level modules provide services to higher-level modules.

Multi-tier Architecture

• System structured in distinct tiers (front-end, middleware, back-end).
• Distinct functionalities are assigned to each tier.

Broker Architecture

• Central broker facilitates communication between clients and servers.
• Services are exchanged through the broker.

Service Oriented Architecture (SOA)

• Breaks down applications to small interconnected services.
• Supports one business need per service.
• Services utilize diverse communication protocols.

SOA with Grid Computing

• Service approach facilitates integration with grid computing resources.
• Clients access distributed resources through the service directory (metadata).

Model-View-Controller (MVC) Architecture

• Separation of concerns (model, view, controller) manages applications structure.
• Model (data), View (rendering), Controller (interaction) simplify complex tasks.

Presentation-Abstraction-Controller (PAC) Architecture

• Application is divided into Presentation, Controller, and Abstraction layers.
• Components communicate through explicit or implicit invocation mechanism.