SOFTWARE ARCHITECTURE AND SOFTWARE PRODUCT LIFE CYCLE Module 1 Contents ◻ Evolution of Software Development ◻ Fundamentals of Software Engineering ◻ Elements of Software Architecture ◻ Management View ◻ Software Engineering View ◻ Engineering Design View ◻ Architectural View What is Software Architecture? ◻ Software architecture presents a view of a software system as components and connectors.
◻ Software Architecture and Software Design methodologies are same? Difference Software architecture and software design methodologies are related but distinct concepts in the field of software engineering.
Software architecture refers to the high-level Software design methodologies are systematic structure of a software system, the discipline approaches to designing software. They provide of creating such structures, and the specific techniques and processes for transforming documentation of these structures. requirements into a design.
- Focus: It focuses on the overall system - Focus: They focus on the individual components of structure, including the major components and the system, their algorithms, data structures, and their interactions, how they fit into the overall detailed workflows. system, and how they communicate with each other.
- Considerations: It involves considerations like - Considerations: It involves considerations like
scalability, performance, security, and object-oriented design, modularity, abstraction, and maintainability. encapsulation.
- Output: Architectural diagrams, patterns, and
principles that guide the overall system - Output: Detailed design documents, class diagrams, sequence diagrams, and design patterns specific to components. Evolution of Software Development
• 1949 • Beginning of software development (binary machine instructions) • Structured • Software design and • Late 1950s Late Engineering development tools • Automatic Programming (first paradigm shift) discipline 1970s (second • 1960s-1970s 1960s was instituted paradigm shift) • Abstract Programming
• Design Late • Beginning Late • UML- of multiviewed Late paradigm 1980s- Software approach 1972 • Information shifted to Architecture 1990s Hiding 1980s Object early Orientation 1990s
Currently we are experiencing a fifth paradigm shift in software development,
where software architecture is an important aspect Fundamentals of Software Engineering
◻ Different roles of Software Engineer
� Software Engineers � Specialists � Software Architects ◻ Dividing labor � Horizontal slicing � Vertical slicing Fundamental Software Engineering Techniques ◻ Reusable Assets � Source code that can be copied and modified � Commercial off-the-shelf (COTS) component � Object-oriented databases ◻ General-Purpose Programming Languages (C++, Java) ◻ Special-Purpose Programming Languages (SQL, Web Technologies) ◻ Modeling Languages and Notations (ERD, UML) Elements of Software Architecture ◻ Components, Connectors, and Qualities ◻ Architectural Description ◻ Software Architecture vs Software Design Methodologies � Software architecture design subsumes and integrates many software design methodologies. ◻ Types of Architecture � Business architecture � Information technology (IT) architecture � Information architecture � Application (software) architecture Characteristics of Software Architecture Modularity ◻ Modularity refers to the decomposition of a software system into smaller, manageable, and interchangeable modules.It Enhances maintainability, allows parallel development, and makes the system easier to understand and modify.
Scalability ◻ Scalability is the ability of the system to handle increasing loads by adding resources either vertically (upgrading existing hardware) or horizontally (adding more nodes).It Ensures that the system can grow and adapt to increasing demands without compromising performance.
Performance ◻ Performance pertains to how efficiently a software system uses resources to provide timely responses and process data. It is Critical for ensuring that the system meets its response time, throughput, and resource utilization goals. Characteristics of Software Architecture
Security ◻ Security involves protecting the system from malicious attacks, unauthorized access, and ensuring data integrity and confidentiality. It is Essential for maintaining trust, protecting sensitive data, and complying with regulatory requirements.
Maintainability ◻ Maintainability is the ease with which a system can be modified to fix defects, improve performance, or adapt to a changed environment.It Reduces the cost and effort required to keep the system operational and up-to-date, enabling longer system lifespans and more efficient evolution.
These characteristics collectively help ensure that the software architecture supports the overall goals and requirements of the system, providing a robust foundation for its development and future growth. The Software Product Life Cycle: Views
◻ Views are ways of categorizing different perceptions
of stakeholders using the Rational Unified Process (RUP) as a foundation. ◻ The views presented are: � Management � Software engineering � Engineering design � Architectural design ◻ Each view of the development process is comprised of phases, activities, tasks, and steps. The Phases of RUP Model ◻ Inception Phase: � Objective: Define the scope and purpose of the project. � Key Activities: ■ Identify key system functionality and use cases. ■ Determine the project's feasibility and risks. ■ Estimate costs and resources. ■ Develop initial project plans, including timelines. ■ Produce a vision document and initial use case model. � Milestone: Lifecycle Objective Milestone. ■ The project’s goals, scope, and constraints are agreed upon, and the project's feasibility is confirmed. The Phases of RUP Model ◻ Elaboration Phase: � Objective: Analyze the project's requirements in more detail and establish a robust architecture. � Key Activities:
■ Refine and expand the use case model.
■ Identify and mitigate key project risks.
■ Define the project's architecture and design.
■ Develop prototypes or proof-of-concept versions of
the system. ■ Create more detailed project plans and schedules.
� Milestone: Lifecycle Architecture Milestone.
■ The architecture is stable, major risks are addressed,
and the project's cost and schedule are refined. The Phases of RUP Model ◻ Construction Phase: � Objective: Build the product. � Key Activities: ■ Develop and implement the remaining components and features. ■ Continuously integrate and test the system. ■ Perform unit, integration, and system testing. ■ Prepare for deployment. � Milestone: Initial Operational Capability Milestone. ■ The system is sufficiently mature and ready for user testing in a controlled environment. The Phases of RUP Model ◻ Transition Phase: � Objective: Transition the system to the user community.
� Key Activities:
■ Beta testing and user acceptance testing.
■ Fine-tuning and correcting any issues identified.
■ Preparing user manuals and training materials.
■ Deploying the system to the user environment.
■ Conducting a post-implementation review.
� Milestone: Product Release Milestone.
■ The product is fully deployed, users are trained, and the system is ready for production use. Management View ◻ Managers expect milestones in a software product development ◻ In modern software methodologies, deliverables are rarely completed before work begins on the next deliverable. ◻ Management view is based on the RUP life-cycle phases. ◻ The RUP defines four fundamental life-cycle phases: � Inception (vision phase) � Elaboration � Construction � Transition Terminologies ◻ Lifecycle Objective Milestone (LCO) ◻ Acquirers: The stakeholders who desire the system are called the acquirers ◻ Builder: The software engineering organization that implements the system is sometimes referred to as the builder ◻ Lifecycle Architecture Milestone (LCA) ◻ The Initial Operational Capability Milestone (IOC) ◻ Product Release Milestone Software Engineering View ◻ The main activities of software engineering are: � Requirements analysis and specification � Design � Implementation and testing � Deployment and maintenance ◻ Each software engineering activity maps to many phases of the management view. Engineering Design View ◻ In this model, the design process is subdivided into four phases: � product planning (Specification of Information) � conceptual design (Specification of Principle) � embodiment design (Specification of Layout) � detailed design (Specification of Production) ◻ Each of these phases focuses on a different level of abstraction and a different set of design objectives. ◻ The design phases do not proceed in a pure serialized fashion. Architectural View ◻ This view focuses on architecture-driven software construction. ◻ The four phases of architecting are as follows: � Predesign phase
� Domain analysis phase
� Schematic design phase
� Design development phase
◻ The four phases above when combined with the following build phases form an architecture-driven software construction method: � Project documents phase
� Staffing or contracting phase
� Construction phase
� Postconstruction phase Synthesizing the Views ◻ Each view contains some overlapping concepts and ways of visualizing the process. ◻ There is no one right way to design and construct software. ◻ You should choose the activities that make the most sense given the project at hand, finding a balance between risk and development speed. SDLC ◻ It stands for Software development Lifecycle. ◻ The Software Development Life Cycle (SDLC) is a structured approach to developing software applications, ensuring that they are built systematically and efficiently. It outlines a series of steps or phases that guide software developers from the initial concept to the final product. Phases of SDLC ◻ Planning ◻ Requirements Analysis ◻ Design ◻ Implementation (or Coding) ◻ Testing ◻ Deployment ◻ Maintenance Types Of SDLC Models ◻ Waterfall ◻ Prototype ◻ Devops ◻ Incremental ◻ Iterative ◻ Spiral ◻ V-Model Types Of Architecture ◻ Software architecture refers to the high-level structure and design of a software system, encompassing the organization of components, their interactions, and how they meet the system's requirements. Several types of software architectures are used, each with different characteristics and suited to various types of applications. ◻ 1. Layered (N-Tier) Architecture ◻ Description: This architecture separates the software system into layers, where each layer has a specific responsibility. Common layers include presentation, business logic, and data access. ◻ Use Case : Enterprise applications, where separation of concerns and maintainability are crucial. ◻ Example: A three-tier architecture with a UI layer, a business logic layer, and a database layer. ◻ 2. Microservices Architecture ◻ Description: In this architecture, the software system is composed of small, independent services that communicate over a network. Each service focuses on a specific business function and can be deployed, updated, and scaled independently. ◻ Use Case: Large-scale applications requiring flexibility, scalability, and rapid deployment. ◻ Example: Netflix's system architecture, where each service (e.g., streaming, recommendations) runs independently. ◻ 3. Monolithic Architecture ◻ Description: A traditional approach where the entire software system is built as a single, indivisible unit. All components are tightly coupled and usually deployed together. ◻ Use Case: Smaller applications or when ease of deployment is prioritized over scalability. ◻ Example: A simple web application with all features integrated into one codebase. ◻ 4. Event-Driven Architecture ◻ Description: This architecture is centered around the production, detection, and consumption of events. Components communicate via event messages, and the system responds to those events asynchronously. ◻ Use Case: Real-time systems, IoT applications, or applications requiring asynchronous processing. ◻ Example: E-commerce systems where an event (e.g., order placed) triggers various services like payment processing, inventory updates, and notifications. ◻ 5. Service-Oriented Architecture (SOA) ◻ Description: Similar to microservices, SOA structures software as services. However, in SOA, services are often larger and more monolithic, providing coarse- grained services that communicate via a common message bus. ◻ Use Case: Enterprises with multiple applications needing to integrate and communicate via well- defined services. ◻ Example: A company-wide enterprise service bus (ESB) that integrates different systems like CRM, ERP, and payment processing. ◻ 6. Serverless Architecture ◻ Description: In this architecture, the infrastructure management (e.g., server provisioning and scaling) is abstracted away. Developers focus on writing functions that are triggered by events, with the cloud provider handling execution and scaling. ◻ Use Case: Applications with unpredictable traffic, needing to scale rapidly and only pay for actual compute time. ◻ Example: AWS Lambda or Azure Functions that execute specific pieces of logic in response to events like API calls or file uploads. ◻ 7. Client-Server Architecture ◻ Description: This is a distributed architecture where clients request services, and servers provide those services. The server hosts and manages resources, while clients access and utilize those resources. ◻ Use Case: Web applications, email systems, or network-based applications. ◻ Example: A web browser (client) interacting with a web server to retrieve and display webpages. ◻ 8. Component-Based Architecture ◻ Description: This architecture breaks the system down into reusable, self-contained components that encapsulate specific functionality. Components interact with each other through well-defined interfaces. ◻ Use Case: Systems requiring modularity and reusability, such as desktop or enterprise applications. ◻ Example: A software development environment (IDE) where different components like code editor, debugger, and compiler interact. ◻ 9. Peer-to-Peer (P2P) Architecture ◻ Description: In P2P architecture, each node (peer) in the network acts both as a client and a server. There is no central authority, and peers directly communicate and share resources with each other. ◻ Use Case: Decentralized applications like file- sharing systems or blockchain networks. ◻ Example: BitTorrent, a file-sharing system where peers upload and download files directly from each other. ◻ 10. Message-Driven Architecture ◻ Description: Components communicate by sending and receiving messages via a message queue. This architecture supports loose coupling and asynchronous communication between components. ◻ Use Case: Systems needing reliable, asynchronous communication, such as financial transaction systems or order processing systems. ◻ Example: A stock trading system where trades are processed through a message broker to ensure reliability and fault tolerance. ◻ 11. Microkernel (Plug-in) Architecture ◻ Description: The core functionality of the system (microkernel) provides the essential services, while additional features are implemented as plug-ins or extensions that interact with the core. ◻ Use Case: Extensible systems like IDEs, where core functionality can be enhanced via plugins. ◻ Example: Eclipse IDE, where the core editor can be extended with various language support plugins. ◻ 12. Domain-Driven Design (DDD) ◻ Description: DDD architecture focuses on modeling the software based on the domain it serves. The design is organized around domain entities, aggregates, and services that reflect the business logic. ◻ Use Case: Complex business systems where aligning software design with business rules is critical. ◻ Example: An inventory management system where domain entities like products, orders, and warehouses drive the architecture. ◻ 13. Hexagonal (Ports and Adapters) Architecture ◻ Description: This architecture emphasizes separation of concerns by structuring the system into the core (business logic) and adapters (interfaces with external systems). The core is agnostic to how it's used or interacted with. ◻ Use Case: Systems that need to be easily adaptable to different interfaces or environments. ◻ Example: An application that can interact with different databases or UI frameworks without changing core business logic. ◻ 14. Pipe-and-Filter Architecture ◻ Description: The system is broken down into a series of processing elements (filters) connected by channels (pipes). Each filter processes input and passes the result to the next filter in the pipeline. ◻ Use Case: Systems that require data transformation, such as compilers, data processing pipelines, or multimedia processing. ◻ Example: A video processing pipeline where each filter adds a different effect to the video stream. ◻ These architectures can also be combined to fit specific application needs. For instance, a microservices architecture can leverage event-driven communication patterns or incorporate serverless components. The choice of architecture depends on factors like system complexity, scalability needs, development practices, and specific business goals. Thank You
