Architectural Modeling and Design

Architectural Modeling and Design

• Involves making representations of system architecture before implementation.
• Allows visualization, analysis, and documentation of a system's components, relationships, and behavior.

Purpose of Architectural Modeling and Design

• Ensures a clear understanding of how the system functions.
• Helps identify potential issues early in development.
• Improves scalability, maintainability, and flexibility.
• Enhances collaboration among developers, architects, and stakeholders.

Software Architecture Pattern

• Defines a software system's high-level structure and organization.
• Outlines fundamental components, their interactions, and the system's overall layout.
• Guides decisions on scalability, performance, and maintainability.
• Focuses on the system's macro-level aspects.
• Establishes a framework for the design and implementation of the entire application.

Design Pattern

• It offers a smaller-scale solution to a recurring design problem within a software component or module.
• Addresses specific design challenges and provides standardized solutions for reusability, readability, and maintainability of code.
• Concerned with micro-level design decisions within a single module or class.
• Contributes to the overall structure defined by the architecture pattern.

Types of System Models

• Structural Models: Represent the static structure of a system, including components, relationships, and interfaces, examples being class diagrams, component diagrams, and deployment diagrams.
• Behavioral Models: Show the dynamic behavior of a system, including interactions, workflows, and state changes, examples being use case diagrams, sequence diagrams, state machine diagrams, and activity diagrams.
• Functional Models: Focus on the system's functionality, describing what the system does, examples being data flow diagrams (DFDs) and functional decomposition diagrams.
• Data Models: Represent data structures, relationships, and constraints in a system, examples being entity-relationship diagrams (ERDs) and database schemas.
• Physical Models: Illustrate the physical deployment and hardware components of a system, examples being deployment diagrams and network topology diagrams.

Layered Architecture Pattern

• A widely used framework in software development.
• Each layer has unique, independent tasks.
• Can modify code inside a layer without affecting others.
• Also referred to as 'N-tier architecture'.

Common Layers in Layered Architecture

• Presentation Layer: The user interface layer for seeing and entering data.
• Application Layer: Handles business logic and workflows.
• Data Access Layer: Manages database connections and queries.
• Data Layer: Contains the database for managing data.

Client-Server Architecture Pattern

• Divides an application into clients and servers.
• Manages data sharing and user interactions.
• Ideal for distributed systems and web-based services.
• Client Layer (Frontend): User interface.
• Business Logic Layer (Middleware/Processing): Processes requests and applies business rules.
• Data Layer (Backend/Database Server): Stores and retrieves data.

Event-Driven Architecture Pattern

• An agile approach where services in software are triggered by events.
• User actions can cause state changes, resulting in reactions considered events.

Model-View-Controller Architecture

• The MVC framework is a design pattern that separates an application into three logical components: Model, View, and Controller.
• Isolates business logic and the presentation layer.
• Traditionally used for desktop graphical user interfaces.
• Model: Manages data logic and interacts with the database.
• View: Handles data presentation and renders dynamically.
• Controller: Manages request flow and does not handle data logic.

Microkernel Architecture Pattern

• Involves both a core system and plug-in modules.
• Core System: Manages the fundamental and minimum operations.
• Plug-in Modules: Handle extended functionalities and customized processing.

Microservices Pattern

• Structures applications as a collection of small, independently deployable services.
• Enables scalability and rapid development, common in cloud-based systems.

Space-Based Architecture Pattern

• Also known as Cloud-Based or Grid-Based Architecture Pattern.
• Addresses scalability issues in large-scale, high-traffic applications.
• Built around a shared memory space accessed by multiple nodes.

Master-Slave Architecture Pattern

• Known as Primary-Secondary Architecture.
• Involves a master component controlling multiple slave components.
• Used for parallel processing and load distribution.
• The master component assigns tasks to slave components.
• The slave component reports results back to the master.

Pipe-Filter Architecture Pattern

• Structures the system around processing elements called filters, connected by pipes.
• Filters process data and pass it to the next filter via the pipe.

Broker Architecture Pattern

• Manages communication between clients and servers in distributed systems.
• A broker component receives client requests and routes them to the correct server or service.

Peer-to-Peer Architecture

• Decentralized network model.
• Each node, or peer, acts as both a client and a server.
• No central authority or single point of control.
• Peers share resources, data, and services directly with each other.

Modeling Notations

Unified Modeling Language (UML)

• Standardized visual modeling language.
• Versatile, flexible, and user-friendly method for visualizing a system's design.
• Software system artifacts can be specified, visualized, built, and documented.
• UML diagrams show the behavior and structure of a system.
• Helps software engineers, businessmen, and system architects with modeling, design, and analysis.
• UML is essential for communicating with non-programmers about necessary requirements, functionality, and system processes, and collaboration.

List of UML Diagram Types

• Structure diagrams show the things in the modeled system, more technically show different objects in a system.
• Behavioral diagrams show what should happen in a system and describe how the objects interact with each other to create a functioning system.

Class Diagram

• A main building block of any object-oriented solution, shows classes in a system, attributes, operations, and the relationship between each class.
• Class has three parts: Name at the top, attributes in the middle, and operations or methods at the bottom.
• Related classes are grouped together and different types of arrows depict the relationships between the classes.

Component Diagram

• Show the structural relationship of components of a software system and are used when working with complex systems with many components.
• Components communicate with each other using interfaces, and the interfaces are linked using connectors.

Deployment Diagram

• Shows the hardware of your system and the software in that hardware.
• Diagrams are useful when your software solution is deployed across multiple machines with each having a unique configuration.

Object Diagram

• Instance diagrams similar to class diagrams, showing relationships between objects using real-world examples.
• They show what a system will look like at a given time and are used to explain complex relationships between objects.

Package Diagram

• Packages group elements, define their interdependencies, and simplify complex class diagrams.
• The UML elements in the package are based on logical relationships.

Composite Structure Diagram

• A type of static structure diagram in UML that shows the internal structure of a classifier, its parts, ports, and connectors.
• Provide a detailed view of how different elements within a classifier (such as a class, component, or deployment node) are composed and how they interact.

Use Case Diagram

• Known as the most known diagram type of the behavioral UML types, diagrams give a graphic overview of the actors involved in a system functions interact, and functions needed by those actors.
• It is a great starting point for any project discussion because you can easily identify the main actors involved and the main processes of the system.

Activity Diagram

• Activity diagrams represent workflows in a graphical way, describe the business workflow or the operational workflow of any component in a system, and are used as an alternative to State machine diagrams.

State Machine Diagram

• State machine diagrams are similar to activity diagrams, the notations are different, they are also known as state diagrams or state chart diagrams.
• They are used to describe the behavior of objects that act differently according to the state they are in at the moment.

Sequence Diagram

• Used to show how objects interact with each other and the order those interactions occur, showing the interactions for a particular scenario.
• Interactions are represented as arrows and are represented vertically.

Communication Diagram

• Similar to sequence diagrams, but the focus is on messages passed between objects.
• The same information can be represented using a sequence diagram and different objects.

Interaction Overview Diagram

• Similar to activity diagrams, interaction overview diagrams can show a sequence of interaction diagrams.
• Interaction Overview diagrams come as a group and happen in order

Timing Diagram

• Used to represent the behavior of objects in a given time frame.
• If its only one object, the diagram is plain, if there is more than one, the diagram shows interactions between objects during that time frame.

High-Level System Design

• Initial step in application development where the overall structure of a system is planned.
• Focus is on how different components work together without internal coding details which helps everyone in the project understand the goals and ensures good communication during development.

Components of High-Level Design

• System Architecture: An overview of the entire system which represents the structure and the relationships between various components. It helps to visually represent how different parts interact and function.
• Modules and Components: Breaks down the systems into modules or components each with specific roles and responsibilities, and contributes to the entire system by helping develop an efficient system.
• Data Flow Diagrams (DFDs): Demonstrates the movement of data within the system, and helps to understand how information is processed and handled.
• Interface Design: Focuses on how different modules communicate with one another by detailing the application programming interfaces (APIs) and user interfaces necessary for seamless interaction between components.
• Technology Stack: Made up of the various technologies and tools that will be used in the development of the system, which includes programming languages, frameworks, and databases.
• Deployment Architecture: Where the system will be hosted and accessed and includes server configurations, cloud infrastructure, and network considerations.
• High-Level Design Document: Consists of data flows, flowcharts, and data structures and helps developers in understanding and implement how the current system is being designed intentionally to function. This document is responsible for explaining the connections between system components and operations which depict the logic, and the architecture design needed (for the system's functionality and flow) for each and every module of the system as per the functional requirements.
• An HLD is usually prepared at the early stages of a software project during the Analysis phase of the SDLC.
• Capacity Estimation in system design involves predicting required resources (processing power, memory, and bandwidth) to meet workload expectations, ensures that a system can handle current and future demands efficiently, and prevent bottlenecking.
• HTTP (HyperText Transfer Protocol) which enables communication between clients and servers transfers data over the web, helps users to requests resources like HTML pages, messages, videos or images, while HTTPS (HyperText Transfer Protocol Secure) which adds extra security through SSL/TLS encryption.
• Web Sockets are important for real-time communication since it allows apps to send and receive data simultaneously which is very useful in web, gaming and chat apps.
• Polling is another way to send and receive data from a server; There are 2 main types of polling:
  • Short polling, the client sends a request to the server and the server immediately sends data at fixed intervals whether the data is updated or not.
  • Long polling, the server waits for the client's request to respond and responds only and only if some new data is available or if some data is being updated.
• Server-Sent Events (SSE) is purposely built as one-way communication from servers to clients in specific design systems, using a technology that helps to push real-time updates from the server to the clients over HTTP connection which Enables users to send data automatically as it becomes available in realtime streaming.
• Rate Limiting restricts the number of events that can be blocked in a timeframe by restricting the number of requests.
• Resiliency Is important because there is always a chance of hardware or software faults which require replication, redundancy and availability to alleviate the issues.
• Paging, in High-Level Design (HLD), refers to the division of datasets or dividing large content to reduce initial load times and make them more manageable.
• Logging Helps to debug the flow of an event in the system and is crucial to monitor the application's flow and the performance of a distributed system to debug issues.