03. SEN418 Software Architecture.pdf

SEN418 Business Application Design and Development Software Architecture  Agenda ▪ Introduction ▪ Software Architectural Patterns ▪ Common Architectural Patterns ▪ Common Architectural Patterns - Comparison ▪ 4+1 View Model of Software Architecture ▪...

SEN418 Business Application Design and Development Software Architecture  Agenda ▪ Introduction ▪ Software Architectural Patterns ▪ Common Architectural Patterns ▪ Common Architectural Patterns - Comparison ▪ 4+1 View Model of Software Architecture ▪ Relation Between 4+1 View Model and Software Architectural Patterns ▪ Architecture Trade-off Analysis Method (ATAM) ▪ Workshop 2/31  Introduction ▪ Software architecture and software design are critical aspects of software engineering. ▪ They involve the high-level design of software systems and their components. ▪ The goal of software architecture and software design is to create systems that are reliable, scalable, maintainable, and performant. ▪ Architects and designers are responsible for creating and maintaining the software architecture and system design. ▪ Good software architecture and software design can have a significant impact on the success of a software project. 3/31  Software Architecture ▪ Software architecture is the high-level structure of a software system. ▪ It describes the system's components, their interactions, and their relationships. ▪ Software architecture provides a roadmap for software development. ▪ It is a blueprint for designing, implementing, and maintaining a software system. ▪ Good software architecture should be flexible, adaptable, and able to accommodate changing requirements. 4/31  Software Architectural Patterns ▪ Software architecture pattern is a reusable solution to a recurring software design problem. ▪ It represents a set of architectural design decisions that provide a solution to a particular problem. ▪ Architecture patterns define the structure of the system, the components, their relationships, and the principles and guidelines governing their interactions. ▪ Patterns promote the principles of good software design, including modularity, scalability, maintainability, and extensibility. ▪ By following a well-known architecture pattern, developers can benefit from the experience of others, reduce development time, and build more robust and reliable software systems. 5/31  Common Architectural Patterns 1. Layered (n-tier) Architecture Pattern 2. Client-Server Architecture Pattern 3. Peer-to-peer (P2P) Architecture Pattern 4. Microservices Architecture Pattern 5. Event-Driven Architecture (EDA) Pattern 6. Service-Oriented Architecture (SOA) Pattern 7. Model-View-Controller (MVC) Architecture Pattern 8. Repository Architecture Pattern 9. Publisher-Subscriber Architecture Pattern 10. Pipe and Filter Architecture Pattern 6/31  Common Architectural Patterns Layered (n-tier) Architecture Pattern ▪ Layered Architecture Pattern divides the system into distinct logical layers. ▪ Each layer has its specific responsibility, promoting modularity and separation of concerns. ▪ Layers can communicate only with the layer immediately above or below them, which improves maintainability and scalability. ▪ This pattern is commonly used in web-based applications and enterprise systems. ▪ Examples of layers include presentation, application, business logic, data access, and data storage layers. 7/31  Common Architectural Patterns Client-Server Architecture Pattern ▪ Client-Server Architecture Pattern is a distributed computing model where the client requests services or resources from the server, which responds by providing the requested service. ▪ This pattern enables high scalability and modifiability. ▪ The server can be optimized to handle large amounts of traffic, while the client can be lightweight and optimized for user experience. ▪ Examples of client-server applications include web applications, email systems, and file-sharing systems. ▪ The pattern is also known as a two-tier architecture. 8/31  Common Architectural Patterns Peer-to-peer (P2P) Architecture Pattern ▪ Peer-to-peer Architecture Pattern is a distributed system where all the nodes in the network are equal, and each node can act as both a client and a server. ▪ Each node can provide resources or services and request resources or services from other nodes. ▪ This pattern promotes scalability, fault tolerance, and self-organization. ▪ Peer-to-peer is commonly used in file-sharing systems, real-time data processing systems, and decentralized communication systems. ▪ Examples of peer-to-peer systems include BitTorrent, Bitcoin, and Skype. 9/31  Common Architectural Patterns Microservices Architecture Pattern ▪ Microservices Architecture Pattern involves breaking down a large, monolithic application into smaller, loosely coupled services that communicate with each other over a network. ▪ Each service is independently deployable, which allows for better scalability and fault isolation. ▪ Microservices are highly resilient, and it enables better fault tolerance since a failure in one service does not affect the entire system. ▪ This pattern is commonly used in large-scale web applications and enterprise systems. ▪ Examples of microservices include authentication, payment processing, and order management services. 10/31  Common Architectural Patterns Event-Driven Architecture (EDA) Pattern ▪ Event-Driven Architecture Pattern is a software architecture that emphasizes the production, detection, consumption, and reaction to events. ▪ An event-driven system is made up of event producers, event consumers, and an event broker that acts as an intermediary between them. ▪ This pattern is commonly used in systems that require high scalability, such as real-time data processing systems and financial trading systems. ▪ Examples of events include user actions, system alerts, and data updates. ▪ The pattern enables a system to be more responsive, adaptable, and fault- tolerant. 11/31  Common Architectural Patterns Service-Oriented Architecture (SOA) Pattern ▪ Service-Oriented Architecture Pattern is a software design pattern that structures a system as a collection of loosely coupled services. ▪ These services communicate with each other over a network and provide a set of functions to other services or client applications. ▪ This pattern promotes reusability, modularity, and scalability. ▪ Examples of services include authentication, payment processing, and order management services. ▪ This pattern is commonly used in enterprise systems and large-scale web applications. 12/31  Common Architectural Patterns Model-View-Controller (MVC) Architecture Pattern ▪ MVC Architecture Pattern separates an application into three interconnected components: Model, View, and Controller. ▪ The Model represents the application's data and business logic, the View displays the data to the user, and the Controller handles user input and updates the Model and View. ▪ This pattern promotes modularity and separation of concerns. ▪ Examples of MVC frameworks include Ruby on Rails and ASP.NET MVC. 13/31  Common Architectural Patterns Repository Architecture Pattern ▪ Repository Architecture Pattern is a pattern that separates the logic that retrieves data and maps it to entities from the business logic that acts on the entities. ▪ The repository acts as a mediator between the data source and the application code. ▪ This pattern promotes modularity, separation of concerns, and testability. ▪ Repository pattern is commonly used in enterprise applications and data-intensive applications. ▪ Examples of data sources include databases, web services, and files. 14/31  Common Architectural Patterns Publisher-Subscriber Architecture Pattern ▪ Publisher-Subscriber Architecture Pattern is a messaging pattern that involves the producers of messages (publishers) and the consumers of messages (subscribers). ▪ Publishers send messages to a broker or message queue, and subscribers receive messages from the broker. ▪ This pattern promotes modularity and loose coupling. ▪ Pub-Sub is commonly used in messaging systems, chat applications, and real-time data processing systems. ▪ Examples of publishers include chat applications, real-time financial trading systems, and social media platforms. 15/31  Common Architectural Patterns Pipe and Filter Architecture Pattern ▪ Pipe and Filter Architecture Pattern is a pattern that involves dividing a system into a set of independent filters that process data and pass it to the next filter through a pipe. ▪ Each filter is independent and performs a specific task, and the pipes connect the filters together. ▪ This pattern promotes modularity and reusability. ▪ Pipe and Filter is commonly used in data processing systems, image processing systems, and signal processing systems. ▪ Examples of filters include data converters, image processing filters, and noise reduction filters. 16/31  Common Architectural Patterns Comparison Microservices Architecture and Service-Oriented Architecture (SOA) ▪ Both focus on breaking down applications into services or components that can be developed, deployed, and maintained independently. ▪ The main distinction is that SOA often emphasizes enterprise-wide service integration and might use heavier protocols like SOAP, while microservices are more about building highly maintainable and scalable applications using lighter protocols such as REST. REST (Representational State SOAP (Simple Object Access Protocol) is Transfer) is an architectural style a protocol-based approach that uses XML that operates over HTTP, using for structured information exchange, methods like GET, POST, PUT, and supporting complex transactions and DELETE. It emphasizes simplicity equipped with comprehensive standards and scalability, utilizing URLs for including security. It's preferred for resources and often employing enterprise-level web services requiring JSON for data exchange. REST is strict contracts. favored for modern web applications due to its ease of use and lightweight nature. 17/31  Common Architectural Patterns Comparison Event-Driven Architecture (EDA) and Publish-Subscribe (Pub/Sub) Model ▪ EDA and Pub/Sub both revolve around the generation, detection, consumption, and reaction to events. ▪ In both patterns, components interact through events to achieve loose coupling. ▪ The Pub/Sub model can be seen as a specific implementation strategy of EDA, focusing on how components subscribe to and publish events. 18/31  4+1 View Model of Software Architecture ▪ The 4+1 View Model of Software Architecture is a popular approach for documenting software architectures. ▪ It provides five different views of the architecture, each representing a different perspective on the system. ▪ The four views are Logical, Development, Process, and Physical, with the fifth view being the Use Case view. ▪ This model provides a comprehensive view of the system and helps architects communicate design decisions to stakeholders. 19/31  4+1 View Model of Software Architecture Logical View ▪ The Logical View describes the functionality of the system from the end- user's perspective. ▪ It focuses on the high-level components of the system and their interactions. ▪ This view is useful for stakeholders who want to understand the system's functionality and how it meets their requirements. ▪ It also helps developers understand the system's architecture and the components they will be building. ▪ The Logical View is typically represented using a class diagram, sequence diagram, or a use case diagram. 20/31  4+1 View Model of Software Architecture Development View ▪ The Development View describes the system's organization into modules or components and how they are mapped to the implementation units such as files, libraries, and executables. ▪ It provides a view of the system that is useful for developers, project managers, and build and release engineers. ▪ This view helps developers understand the system's architecture and how it can be built and tested. ▪ It also helps project managers plan the development effort and track progress. ▪ The Development View is typically represented using a component diagram or a deployment diagram. 21/31  4+1 View Model of Software Architecture Process View ▪ The Process View describes the system's runtime behavior and how the components interact with each other at runtime. ▪ It focuses on the system's concurrency, synchronization, and performance characteristics. ▪ This view is useful for architects, performance engineers, and testers who need to understand the system's runtime behavior. ▪ It helps architects identify potential bottlenecks, race conditions, and synchronization issues. ▪ The Process View is typically represented using a sequence diagram, activity diagram, or a state-chart diagram. 22/31  4+1 View Model of Software Architecture Physical View ▪ The Physical View describes the physical structure of the system and how it is deployed across hardware and network infrastructure. ▪ It focuses on the system's scalability, availability, and security characteristics. ▪ This view is useful for system administrators, network engineers, and security engineers. ▪ It helps them understand how the system is deployed, how it can be scaled up or down, and how it can be secured. ▪ The Physical View is typically represented using a deployment or a network diagram. 23/31  4+1 View Model of Software Architecture Use Case View ▪ The Use Case View describes the system's functionality from the end-user's perspective using use cases. ▪ It provides a view of the system that is useful for business analysts and requirements engineers. ▪ This view helps them understand the system's functionality and how it meets the user's requirements. ▪ It also helps developers understand the system's requirements and how they can be implemented. ▪ The Use Case View is typically represented using a use case diagram or a use case narrative. 24/31  Relation Between 4+1 View Model and Software Architectural Patterns ▪ The 4+1 view model and software architectural patterns are related in that they both provide guidance for designing software systems at different levels of abstraction. ▪ The 4+1 view model provides a conceptual framework for describing a software system from multiple perspectives, including the logical, development, process, physical, and use case perspectives. This model can help to ensure that all stakeholders in a project have a clear understanding of the system's architecture and design. ▪ Software architectural patterns, on the other hand, provide specific solutions to common architectural problems that arise in software systems. These patterns are often implemented within one or more of the views in the 4+1 view model. ▪ For example, the Layered architecture pattern can be used to organize the logical view of a system, while the Client-Server architecture pattern can be used to organize the physical view of a system. Similarly, the Model-View-Controller (MVC) pattern can be used to organize the development view of a system. ▪ In this way, the 4+1 view model and software architectural patterns can work together to provide a comprehensive approach to designing and building software systems. 25/31  Architecture Trade-off Analysis Method (ATAM) ▪ The ATAM is a method for evaluating software architectures against multiple quality attributes or non-functional requirements, such as scalability, reliability, maintainability, and performance. ▪ The ATAM approach helps to identify risks and trade-offs associated with different architectural decisions and provides a framework for making informed decisions. ▪ The process involves multiple steps, including defining quality attribute scenarios, evaluating the architecture against the scenarios, and identifying trade-offs and risks. ▪ The ATAM approach is iterative and encourages feedback from stakeholders, allowing for adjustments and improvements to be made to the architecture. 26/31  A Sample Scenario with ATAM ▪ Scenario: A company is planning to develop a new e-commerce platform. The platform will allow customers to purchase products and services online, and it will also include features such as a shopping cart, order tracking, and a customer service portal. The company wants the platform to be scalable, reliable, and secure, with fast response times and high availability. ▪ ATAM Analysis: Step 1: Identify Quality Attribute Scenarios Step 2: Evaluate the Architecture Step 3: Identify Trade-Offs and Risks Step 4: Refine the Architecture Step 5: Iterate and Improve 27/31  A Sample Scenario with ATAM ▪ Step 1: Identify Quality Attribute Scenarios The quality attribute scenarios for the e-commerce platform could include: o Scalability: The platform should be able to handle a large number of concurrent users and transactions, and it should be able to scale up or down as needed. o Reliability: The platform should be highly available and reliable, with minimal downtime and data loss. o Security: The platform should be secure, with strong authentication and authorization mechanisms, and protection against common security threats such as SQL injection and cross-site scripting. o Performance: The platform should have fast response times and high throughput, with minimal latency and network overhead. 28/31  A Sample Scenario with ATAM ▪ Step 2: Evaluate the Architecture The architecture of the e-commerce platform could be evaluated against the quality attribute scenarios using various methods, such as architectural reviews, simulations, or prototypes. The evaluation could focus on different architectural elements, such as the system's components, interfaces, or data flows. ▪ Step 3: Identify Trade-Offs and Risks Based on the evaluation, the team could identify potential trade-offs and risks associated with the architecture. For example, the use of a distributed architecture could improve scalability and reliability but could also introduce performance overhead and security risks. The use of caching and load balancing techniques could improve performance but could also increase complexity and maintenance costs. 29/31  A Sample Scenario with ATAM ▪ Step 4: Refine the Architecture Based on the identified trade-offs and risks, the team could refine the architecture to address the issues and improve the quality attributes. For example, the team could use a combination of caching, load balancing, and content delivery network (CDN) techniques to improve performance while reducing complexity. They could also implement security measures such as encryption, access controls, and firewalls to mitigate security risks. ▪ Step 5: Iterate and Improve The ATAM process is iterative and encourages feedback from stakeholders, allowing for adjustments and improvements to be made to the architecture. The team could repeat the evaluation and refinement process to further improve the quality attributes and address any new trade-offs or risks that may arise. 30/31  Workshop Designing a Scalable E-commerce Platform Background: ▪ You've been tasked with designing the software architecture for an up-and-coming e- commerce platform, "ShopFast." The platform aims to provide a seamless shopping experience for customers with features like product browsing, search functionality, user reviews, shopping carts, and online payment processing. ShopFast expects rapid growth in user traffic and product listings, necessitating a highly scalable, maintainable, and secure architecture. Requirements: Challenges: ▪ Scalability: Must support scaling to accommodate increasing loads,▪ Handling fluctuating and potentially massive especially during peak shopping seasons. traffic volumes. ▪ Performance: Should ensure fast response times for search queries▪ Managing a large and growing inventory of and page loads. products. ▪ Availability: Needs to be highly available to minimize downtime and ▪ Ensuring quick and relevant search results. maintain a positive user experience. ▪ Protecting sensitive user data. ▪ Security: Must secure user data, especially payment information, ▪ Facilitating smooth deployment of new against breaches and attacks. features without significant downtime. ▪ Maintainability: Should be easy to update and maintain, allowing for quick feature rollouts and bug fixes. ▪ Suggest two patterns. Discuss requirements, address challenges. ▪ Compare two patterns in terms of requirements. 31/31