Class#5 Software Architecture PPT PDF

CLASS#5  Recap Documentation ----- Technical team ----- SRS document UML API User stories...

CLASS#5  Recap Documentation ----- Technical team ----- SRS document UML API User stories (functional, non- HLD, LLD Diagrams Documentation functional) ----- Business team ----- Famous Sequence Class Architectur Diagrams Diagrams es Design Patterns HLD & LLD HLD & LLD EXAMPLE DOCUMENTS SOFTWARE ARCHITECTURE VISUALIZATION (C4 MODEL) The C4 Model is a framework for visualizing the architecture of software systems in a way that is easy to understand. It was created by Simon Brown and is widely used for designing, documenting, and understanding software architectures. The C4 Model breaks down the architecture into four hierarchical levels, with each level giving a different level of detail: 1.Context (Level 1): Shows the big picture of the system and its interactions with external entities. 2.Container (Level 2): Focuses on the major containers (applications, services, databases) that make up the system. 3.Component (Level 3): Delves deeper into the components within each container. 4.Code (Level 4): Provides a close-up of the actual code structure for a particular component (usually with UML or similar diagrams). 5 CONT EXT CONTA INER COMP ONENT CODE FAMOUS SOFTWARE ARCHITECTURES MONOLITHIC ARCHITECTURE Monolithic Architecture represents a traditional and unified approach where all components of an application are tightly integrated into a single, cohesive unit. In a monolithic application, the user interface, business logic, and data access layers are all bundled and deployed as a single unit. 12 MODEL-VIEW-CONTROLLER (MVC) The Model-View-Controller (MVC) pattern is a time-honored architectural paradigm that separates an application into three interconnected components. Insert Confidentiality Level in slide footer 13 EVENT-DRIVEN Event-Driven Architecture relies on events to trigger and communicate between different components. It operates on the principle of asynchronous communication, where events in one part of the system trigger actions or responses in another part. Example: Netflix recommendations 14 SOA Service-Oriented Architecture (SOA) structures an application as a set of loosely coupled, independent services that communicate with each other. Each service exposes its functionality through standardized protocols. Insert Confidentiality Level in slide footer 15 Example: MICROSERVICES ARCHITECTURE Microservices Architecture is a modern approach that decomposes an application into a set of small, independent services. Each service runs its own process and communicates with other services through APIs. 16  Recap Documentation ----- Technical team ----- SRS document UML API User stories (functional, non- HLD, LLD Diagrams Documentation functional) ----- Business team ----- Famous Sequence Class Architectur Diagrams Diagrams es Design Patterns UML DIAGRAM UML is a common language for business analysts, software architects and developers used to describe, specify, design, and document existing or new business processes, structure and behavior of artifacts of software systems. USE CASE DIAGRAM SEQUE NCE DIAGR AM To show the interactions between objects in the sequential order that those interactions occur. CLASS DIAGRAM CLASS DIAGRAM ATTRIBUTE S CLASS DIAGRAM RELATIONS INHERITANCE “is-a” relations ship. Square is a Shape. ASSOCIATIONS A single student can associate with multiple teachers: The example indicates that every Instructor has one or more Students: We can also indicate the behavior of an object in an association (i.e., the role of an object) using role names. Cardinality AGGREGATION Part of, but each one can be stand a lone COMPOSITION Part-of, but can’t be standalone  Recap Documentation ----- Technical team ----- SRS document UML API User stories (functional, non- HLD, LLD Diagrams Documentation functional) ----- Business team ----- Famous Sequence Class Architectur Diagrams Diagrams es Design Patterns APIs API (Application Programming Interface), which is a set of rules that allows different software systems to communicate with each other. An API contract is a formal agreement that defines how two systems will interact with each other through an API. An API contract is crucial because it prevents ambiguity and makes integration easier. API CONTRACT Endpoint Definitions (URI path) HTTP Methods (e.g., GET, POST, PUT, DELETE) Request Structure Path, Parameters,.. Response Structure JSON, XML, Status Codes (200, 400, 500) Error Codes Authentication protocols API CONTRACT Endpoint Definitions: Each API endpoint (URL path) is specified, describing the exact resource it provides access to. For example, an endpoint might be /api/v1/users for accessing user data. HTTP Methods: The contract specifies which HTTP methods (e.g., GET, POST, PUT, DELETE) can be used on each endpoint. For instance: GET for retrieving data POST for creating new resources PUT for updating resources DELETE for removing resources API CONTRACT Request Structure:  Path Parameters: Parameters required in the endpoint's URL (e.g., /api/v1/users/{userId} where {userId} is a path parameter).  Query Parameters: Optional parameters that modify the request (e.g., /api/v1/users?status=active).  Headers: Required headers for each request, such as authentication tokens or content type specifications.  Request Body: For methods like POST or PUT, the contract details the exact structure of the request payload. For example, when creating a new user, the API contract may require JSON data with specific fields (like name, email, age). API CONTRACT  Response Structure: Status Codes: Each endpoint specifies possible HTTP status codes (e.g., 200 for success, 404 for not found, 500 for server error) to indicate different outcomes of a request. Response Body: The exact format of the response, typically in JSON or XML. For example, if you request a user profile, the contract might specify that you’ll get back a JSON object with fields like id, name, email, and createdAt.  Error Codes and Messages: A list of possible error codes and what each means, along with any expected error messages, to help clients handle issues effectively.  Data Types and Constraints: The contract often specifies data types for each field (e.g., string, integer, boolean) and any constraints, like required fields, minimum or maximum values, and allowed formats.  Authentication Requirements: Specifies how to authenticate requests, such as with an API key, OAuth token, or JWT, and which endpoints require authentication.  Recap Documentation ----- Technical team ----- SRS document UML API User stories (functional, non- HLD, LLD Diagrams Documentation functional) ----- Business team ----- Famous Sequence Class Architectur Diagrams Diagrams es Design Patterns