Software Architecture Part 1 PDF

Software_Architecture_Part_1 Introduction : The high-level design of a software system, focusing on its structure rather than code details. It involves: a. Identifying components, elements, and subsystems. b. Defining their behavior and interfaces. The bridge from requirements to desig...

Software_Architecture_Part_1 Introduction : The high-level design of a software system, focusing on its structure rather than code details. It involves: a. Identifying components, elements, and subsystems. b. Defining their behavior and interfaces. The bridge from requirements to design, defining the system's high-level structure and guiding detailed designs like UI, database, and class diagrams. Importance of Software Architecture: a. Facilitates communication among stakeholders and developers of how requirements would be implemented. b. Highlights impactful early design decisions (that impact all the SE work that follows). c. Serves as a blueprint (prototype) for system structure and interactions (between components). Who does the Software Architecture : Software Architect a. Creates fast, secure, reliable, and maintainable systems. b. By : Selecting the optimal technologies and patterns to meet requirements. c. He Must be: Skilled in tools, have a good understanding of specifications, and programming → (To ensure the feasibility of the architecture that he made, without wasting the time). How to Become a Software Architect: a. Start as a Software Developer. b. Gain 5+ years of diverse development experience. Software Architecture Process : 1. Understand the Functional Requirements : a. System Goals, List the functional use cases. 2. Understand the Non-Functional Requirements: (More important than the FR).  a. Define Technical and Service Level attributes. (#Users, Performance, data volume...). 3. Map the Components: a. Define the components, modules or subsystems. b. Outlining their goals, tasks, and functionalities. 4. Select the Technological Stack: (SUPER IMPORTANT) a. Done by the Architect with the help of the developers). b. Choose the platforms/frameworks, languages, tools APIs for backend, frontend, data, and communication. c. Because: i. Changes are costly, cause delays. ii. Risk bias toward familiar but suboptimal technologies. d. Factors to consider when choosing the technology: i. Can perform the task and all the specifications required. ii. Has Large Active Community and Support ? iii. Popularity: it can give better insights on performance portability and richness of features. iv. Licensing and Cost. v. Maintenance and future upgrades. vi. Documentation. vii. Legal Issues and Regulations. e. Backend technologies. f. Frontend technologies. g. Data Storage technologies. h. Communication technologies (REST...). 5. Design the Architecture: (Based on what we said) 6. Write the Architecture Document : a. Architects produce an architectural document describing the high-level process. 7. Support the Development Team: a. The architect needs to support the team: i. Ensures the team follows the architecture. ii. Addresses any issues or adjustments needed due to unforeseen problems. Architecture Quality Attributes:  Quality Attributes (*-ilities) ⇾ (non-functional requirements) a. Technical capabilities that should be used to implement the non-functional requirements. b. (-ilities) include : i. Scalability: Capacity to handle heavy load due to an increase of: 1. N° Users, Data size, Running or deployed instances. 2. Types of scalability: 1. Scale Up (Vertical) : Add more processors, RAM, Hard-drives. 2. Scale Out : Add more machines, VMs to the pool of servers. ii. Modularity: 1. Building a system from independent components that can be changed or replaced without affecting the whole system. 2. 3. Extensibility : 1. Add new features without modifying its existing code 2. We use design patterns. 4. Manageability 1. The ability to monitor (know what's going on) and improve the software performance in real-time. 2. Self-reporting helps automate management and enhances fault tolerance, allowing the system to recover and continue functioning after failures. 5. Others: - Reliability, Availability, Usability, Maintainability, Portability, Security, Performance, Cost Efficiency. Software Architectural Styles What’s an Architectural Style: a. An Architectural Style is a reusable solution for structuring components, using proven patterns to address common software problems. It defines the  overall system structure, while Architecture Patterns focus on specific building blocks (individual structural elements). b. Architecture Classification a. Monolithic Architectures: i. Single deployment Unit. ii. Good Points : Must easier to design and implement Inexpensive Deployed more quickly. iii. Weak points: Scalability (Only Vertical) Fault tolerance. b. Distributed Architectures: i. Multiple deployment Units. ii. Good Points : Scalability (Up or Out) Performance Fault Tolerance. iii. Weak Point : Expensive Maintenance Complexity. Architecture Partitioning: a. Architects can design and group functionalities into components using either: i. Technical Partitioning: (organizes components based on their technical role) 1.  ii. Domain Partitioning:(aligns the software system with the business domain) 1. Data-Centred (Repository) Architecture Style: a. A central data store (e.g., database) is accessed by components that modify or retrieve data. b. Components are unaware of each other's data or states. Pipe and Filter Architecture Style: a. Components (filters) are connected by pipes that pass data. b. Each filter processes data independently and passes it to the next filter in a suitable form. Model-View-Controller (MVC) Architecture Style: a. Composed of 3 components: i. Model: Handles data and business logic. ii. View: Manages user interface and presentation. iii. Controller: Coordinates data flow between the model and view. Layered Architecture Style: a. Contains a number of layers, where each layer has a specific role and responsibility within the application. b. Closed Layers: Only adjacent layers can communicate, ensuring isolation. c. Isolation: Changes in one layer don't affect others (e.g., changing data access doesn't impact business logic or UI). d. When to Use: Simple, monolithic applications with isolated changes (e.g., changing business rules or UI). e. When Not to Use: Small projects, tightly coupled layers, or when performance and scalability are key concerns. Microkernel Architecture Style -Plug-in Architecture Style- : a. Flexible and Extensible: Allows adding new functionality via extensions or plugins without modifying the core system. b. When to Use: Product-based apps with planned extensions, or systems with multiple/custom configurations (e.g., cloud, file systems, different services). c. When Not to Use: If scalability is a concern (core system may become a bottleneck-The core system slow down the performance), or frequent changes to the core system can break plugins. Event-Driven Architecture (EDA): a. Is an architectural style where the system responds to events asynchronously. Events are actions or changes in state that trigger specific processes. b. In EDA: i. Event Producers trigger events (e.g., a user clicking a button). ii. Event Consumers or Event Processors respond to those events (e.g., updating the database or sending notifications). iii. Components are decoupled, meaning they don't directly interact with each other but communicate through events. This allows the system to be more flexible, scalable, and responsive to changes. Microservice Architecture Style: a. A microservice is defined as a single-purpose, separately deployed unit of software that does one thing really, really well.