software achitucture
unit 1
An efficient summary of the topics is provided below.
1. Software Development Methodology
A software development methodology is a framework used to structure, plan, and manage the process of creating software.
Importance
Structure and Management: Provides a structured approach to manage the development life cycle.
Predictability: Helps ensure software delivery is within time and budget.
Risk Mitigation: Minimizes project risks through defined processes.
Quality: Contributes to higher software quality through consistent practices.
2. Waterfall Model
The Waterfall model is a linear and sequential approach where each phase of the Software Development Life Cycle (SDLC) must be completed before the next phase begins, like a cascading waterfall.
Phases (Typically)
Requirements Gathering and Analysis
System Design
Implementation (Coding)
Integration and Testing
Deployment
Maintenance
Limitations
Rigidity: Doesn't allow for much flexibility or adaptation once a phase is completed.
Late Feedback: The customer only sees the working software late in the cycle (at the testing or deployment phase), making changes costly.
High Risk with Unclear Requirements: If requirements are incomplete or misunderstood at the start, major problems may arise late in the process.
Testing Delay: Testing happens only after the entire implementation is complete.
3. Agile Methodology vs. Spiral Model
4. Software Quality Model
A software quality model is a framework that defines the attributes or factors that contribute to the quality of a software product.
McCall's Quality Model
McCall's Quality Model is one of the earliest models, defining software quality in terms of a hierarchy of three broad perspectives, which are further broken down into 11 quality factors:
Product Operation (As-Is): Factors related to the immediate use of the software.
Factors: Correctness, Reliability, Efficiency, Integrity, Usability.
Product Revision (Change): Factors related to modifying the software.
Factors: Maintainability, Flexibility, Testability.
Product Transition (Adaptation): Factors related to adapting the software to new environments.
Factors: Portability, Reusability, Interoperability.
This model helps map a user's high-level quality concerns (e.g., "It's easy to use") to the measurable characteristics used by developers (e.g., "Code is well-documented").
5. Architectural Model, Reference Model, and Reference Architecture
Architectural Model: A descriptive representation of a specific system's architecture, showing its components, their relationships, and the principles governing their design and evolution. It is a concrete design for an actual solution.
Reference Model: An abstract framework for understanding significant elements within a particular domain.
It provides a common taxonomy and ontology (vocabulary) for discussing the domain's functional aspects, independent of any specific solution or technology. It is purely conceptual and not directly implementable. Reference Architecture: A template solution for an architecture within a particular domain or product line.
It's more concrete than a reference model, providing reusable designs, architecture patterns, and best practices. It acts as a constraint and starting point for concrete architectural models.
Relationships
The Reference Model provides the fundamental vocabulary and functional breakdown for a domain.
The Reference Architecture is built upon the reference model, providing a generalized structural and technical template using that vocabulary.
The Architectural Model for a specific project is created by instantiating (applying and adapting) the reference architecture to meet unique project requirements.
6. Issues Faced in Different Software Development Models
Many issues are common across models, but different models may exacerbate or mitigate certain problems:
Requirements Issues (All Models, but especially Waterfall): Unclear, incomplete, or ever-changing requirements lead to scope creep, delays, and costly rework, especially in linear models where changes are discouraged mid-phase.
Integration and Testing Issues (Waterfall): Discovering bugs and integration challenges late in the cycle (during the testing phase) makes them much harder and more expensive to fix.
Risk Management (Waterfall): The lack of explicit, early risk assessment means major technical or project risks are often identified too late.
Communication Barriers (All Models): Poor communication between stakeholders, developers, and testers can lead to misinterpretations and software quality conflicts.
Technical Debt (Agile): The push for rapid releases and short sprints can sometimes lead to premature optimization or taking shortcuts, accumulating technical debt if not actively managed.
Project Control (Agile/Spiral): Difficulty in time and cost estimation can be higher in highly iterative models where the final scope evolves over time.
Complexity (Spiral): The Spiral model's heavy emphasis on risk analysis and documentation for each loop can introduce significant process overhead and complexity.
7. Architecture Business Cycle (ABC)
The Architecture Business Cycle (ABC) is a model that describes the cyclical relationships and influences between a system's software architecture, the requirements for the system, and the technical, business, and social environments in which it is created and fielded.
The cycle shows:
Influences on Architecture: Stakeholders, the developing organization's goals, the architect's experience, and the technical environment all shape the resulting software architecture.
Effects of Architecture: The resulting architecture, in turn, influences and feeds back to affect the developing organization (e.g., its structure, its market goals) and the requirements for the next generation of systems.
Importance
The ABC is important because it provides a comprehensive framework for understanding the long-term impact of architectural decisions.
Organizational Structure: The architecture often dictates how development teams are structured.
Future Requirements: A successful architecture can enable a business to capitalize on a market, thereby influencing its future business goals and the requirements for subsequent systems.
Strategic Planning: Managing the ABC allows a business to control the feedback loops to accommodate growth, expand its market, and efficiently leverage past architectural investments.
1. Software Architecture Models and Their Need
Software Architecture Models (or architectural patterns/styles) are fundamental, recurring design solutions to commonly faced problems in software engineering. They describe the high-level structure of a software system by defining the components, their responsibilities, and the rules governing their relationships and interactions.
Need for Different Models
The need for different models arises because no single architecture is optimal for all systems. Different systems prioritize different quality attributes (non-functional requirements).
Architects choose a model based on project scope, team size, required performance, data volume, expected change rate, and the core business goals.
2. Structural Models vs. Dynamic Models
3. Framework Models in Software Architecture
A framework model (or software framework) is a collection of reusable, generic software components that provides a skeleton or structural blueprint for developing applications in a specific domain. It dictates the overall architecture and controls the flow of execution, with developers filling in the custom business logic.
A key feature is Inversion of Control (IoC): the framework calls the developer's code (the "Hollywood Principle": "Don't call us, we'll call you"), unlike a library where the developer's code calls the library functions.
Example:
Web Application Frameworks: Django (Python) or Spring Boot (Java). These frameworks provide the architecture for handling HTTP requests, routing, database connectivity, and security, allowing the developer to focus only on creating the specific business logic for their web application (e.g., e-commerce cart, blog post creation).
4. Process Model in Software Architecture
A process model in software architecture (often referred to as a Software Process Model or SDLC model) is an abstract representation of the sequence of activities and tasks involved in developing and maintaining a software system. It dictates when and how architectural activities (design, documentation, evaluation) are performed.
Example: Incremental Development Model Instead of building a complete system at once, the incremental model produces the system in small, functional releases (increments). The architectural design process is often evolutionary: a core architecture is designed for the first increment, and it is refined, adapted, or extended in subsequent increments as requirements become clearer. This iterative approach allows the architecture to be continuously validated with working software.
5. Dataflow Architecture
Dataflow architecture is an architectural style where the system is organized around the flow of data. The entire system is viewed as a series of transformations applied to input data until it becomes the final output. The main components are:
Processors (Filters): Independent components that transform data.
Data Channels (Pipes): Unidirectional streams that connect processors, passing data from one stage to the next.
Usage
Dataflow architecture is primarily used in systems that involve complex, sequential data processing:
Compilers: Code passes through lexical analysis, parsing, semantic analysis, and code generation.
Signal Processing: Audio or video streaming processing pipelines (e.g., decoding, filtering, encoding).
ETL (Extract, Transform, Load) Systems: Used for data warehousing and business intelligence.
6. Pipes and Filters Architecture
The Pipes and Filters architecture is a common dataflow style where a system is broken down into two main components:
Filters: Independent, self-contained components that read data from input streams, perform a specific transformation (e.g., sorting, filtering, validation), and write the result to an output stream. They are unaware of the filters before or after them.
Pipes: Connectors that transfer the output stream of one filter to the input stream of the next. They are typically unidirectional and do not modify the data.
Real-World Example
The most common real-world example is the Unix/Linux Command Line Shell:
Filters: Commands like
ls(list files),grep(filter lines),sort(order lines), andwc(count words).Pipes: The vertical bar symbol (
|) connects the output of one command to the input of the next.
Example Command: ls -l | grep ".txt" | sort
The
ls -lfilter generates a list of files.The output is piped to the
grep ".txt"filter, which transforms the list by keeping only lines containing ".txt".The result is piped to the
sortfilter, which orders the remaining lines.
7. Call-and-Return Architecture
The Call-and-Return architectural style is the most traditional and dominant form, where the main program logic is decomposed into smaller, reusable program units (sub-programs or modules). The components interact via a procedure call or function call mechanism, resulting in a hierarchical control flow.
Common Forms: Main Program/Subroutine, Object-Oriented systems, and Layered Architecture.
Advantages
Modularity: Promotes high cohesion and low coupling between modules, making code easier to understand and manage.
Reusability: Subroutines can be called from many different places.
Testability: Individual modules/subroutines can be tested in isolation.
Scalability: Allows for the replacement of a module as long as its interface remains unchanged.
Disadvantages
Tight Coupling: The calling module must know the name and interface of the called module, creating a dependency.
Limited Scalability: If the entire system is a single program, scaling the whole application is often necessary, even if only one part is the bottleneck.
Control Flow Rigidity: The execution flow is rigid and synchronous (caller waits for the callee to return), which can lead to performance degradation in distributed systems.
8. Data-Centered Architecture
Data-Centered Architecture (or Repository Architecture) places a central data store (the repository) at the core of the system. Components (clients, agents) access, modify, and manage the shared data within this central store. Components operate independently, communicating only through the repository.
How it Differs from Layered Architecture
9. Agent-Based Architecture
Agent-Based Architecture is an architectural style where the system is composed of multiple autonomous agents. An agent is a self-contained, goal-oriented software component that can perceive its environment, make decisions, communicate with other agents, and act without direct human or system intervention. Agents are typically intelligent, adaptive, and proactive.
Applications
Autonomous Robotics and Vehicles: Agents control different subsystems (navigation, sensor fusion, motor control) in self-driving cars or drones, coordinating to achieve the goal of safe travel.
Simulation and Modeling: Used in social science or ecological simulations where a large number of independent entities (agents) need to interact and adapt to model complex system behavior.
Complex Systems Management (e.g., Smart Grids): Autonomous agents manage distributed resources, monitoring energy load and making real-time adjustments to optimize power distribution and consumption.
10. Microservices Architecture
Microservices Architecture is an approach where a large application is structured as a suite of small, independent services, each running its own process and communicating using lightweight mechanisms (like HTTP APIs).
Key Characteristics:
Decentralized: Services can be developed, deployed, and scaled independently.
Business-Capability Oriented: Each service is focused on a single business domain function (e.g., Order Processing, User Management, Product Catalog).
Technology Diversity: Teams are free to choose the best programming language, database, and frameworks for their specific service.
Resilience: Failure in one service is isolated and does not necessarily crash the entire application.
11. Reactive Architecture
Reactive Architecture is an architectural style based on the principles outlined in the Reactive Manifesto, designed to build systems that are robust, highly available, and responsive under heavy load. It is a set of design principles rather than a single pattern.
Key Features (The Four Principles):
Responsive: The system responds in a timely manner, ensuring fast and consistent response times.
Resilient: The system stays responsive even in the face of failure. It uses isolation, self-healing, and replication.
Elastic: The system remains responsive under varying workload by scaling up or down dynamically, with no contention or bottlenecks.
Message-Driven: Components communicate exclusively by asynchronous message passing (events), ensuring loose coupling, isolation, and better flow control (backpressure).
Importance in Modern Systems
It is gaining importance because modern applications must handle:
High Concurrency: Millions of users and devices accessing the system simultaneously.
Continuous Availability: Users expect 24/7 uptime and a seamless experience.
Geo-Distribution: Data and services are spread across multiple clouds and regions.
Reactive principles are essential for achieving the high scalability and resilience required by streaming, real-time data, and globally distributed services.
12. REST Architectural Style
REST (Representational State Transfer) is an architectural style for designing distributed hypermedia systems, most famously applied to the World Wide Web and web APIs (RESTful APIs). It emphasizes simple, stateless communication.
Principles (Constraints)
Client-Server: The client and server are strictly separated. The client is concerned with the user interface, and the server is concerned with data storage. This separation allows them to evolve independently.
Stateless: Each request from client to server must contain all the information needed to understand the request. The server must not store any client context between requests. This improves scalability and reliability.
Cacheable: Responses must explicitly define themselves as cacheable or non-cacheable to prevent clients from using stale data. This improves performance and reduces server load.
Uniform Interface (Crucial): Defines how the client interacts with the server through a standardized interface. Key elements include:
Resource Identification: Resources are identified in requests (e.g., using a URI:
/users/123).Manipulation via Representations: Resources are manipulated by clients sending representations (e.g., JSON or XML) back and forth.
Self-Descriptive Messages: Messages include enough information to describe how to process them (e.g., using HTTP methods like GET, POST, DELETE).
HATEOAS (Hypermedia As The Engine Of Application State): The server's response should contain links to guide the client to the next possible actions.
Example: Statelessness Principle
A client requests to retrieve user details.
Non-RESTful (Stateful): Client sends a request, assuming the server remembers they logged in during a previous session. If the server crashes or the session expires, the request fails.
RESTful (Stateless): Client sends a request that includes an Authentication Token in the header. The server uses only this token to authenticate and process the request, with no memory of past interactions.
Comments
Post a Comment