::::success
# CSN Lab № 2 Assignment: Architecture Patterns
**Name: Khasan Abdurakhmanov**
::::
##
:::info
<center>

### PART A
</center>
:::

<center>

### Task 1

</center>

### 1.1. Provide 3 unique definitions for software architecture.

* Software Architecture defines fundamental organization of a system and more simply defines a structured solution. It defines how components of a software system are assembled, their relationship and communication between them. It serves as a blueprint for software application and development basis for developer team.*

* Software architecture is the shared understanding that the expert developers have of the system design.

* It is more like the decisions you wish you could get right early in a project.

### 1.2. List and explain with sample diagrams, 3 types of software architecture.

1. *Monolithic architecture* is a traditional style where all application components are grouped as a single unit. In this architecture, modules are tightly coupled, making it difficult to maintain and scale the application. However, it is simple to implement and deploy. For example *Netflix* will be a typical video streaming application, in which the user will be able to watch movies, series, documentaries and so on. The user will be able to use the app in web browsers, in a mobile app, and on a TV app, too. So what we have? The main services included in our app will be authentication (so people can create accounts, login, and so on), payments (so people can subscribe and access the content) and streaming of course (so people can actually watch what they're paying for).
<center>

Figure 1: A classic monolithic architecture
</center>

On the left, we see three different front-end applications that will act as clients in this system. They can be developed in React or React-native, for example. We have a single server that will accept requests from all three client applications, interact with the database when needed, and respond to each front-end accordingly. The back-end can be developed on, say, Java and Node.
This architecture is called a **monolithic** architecture because a single server application is responsible for all system functions. In our case, if a user wants to authenticate, pay us or watch one of our films, all requests will be sent to the same server application.
**The main advantage of the monolithic design is its simplicity.**

2. Consider a situation where server response time delays have been observed recently. Despite vertical scaling (adding additional RAM and GPU), the server is not handling the load. In addition, we continue to develop new features for our system, including a recommendation tool that reads users' preferences and suggests films that match their profile. This has resulted in a large and complex code base. Upon analysis, we found that the streaming feature consumes the most resources, while other services such as authentication and payments are much less loaded. To solve this problem, we implement a **microservices architecture** as follows:

<center>


Figure 2: Microservices implementation
</center>

**Microservices** is the concept of dividing server-side features into many small servers, each responsible for only one or a few specific features.
In a **monolithic** architecture, a single server is responsible for all features. After implementing microservices, there will be a server for authentication, another for payments, another for streaming, and one for recommendations.
While **microservices** architecture is more complex to set up and manage, it makes sense for very big projects. Most projects start out as **monoliths** and **migrate** to microservices only when needed for performance reasons.

3. **Event-driven architecture** is an architecture style where the application is designed to respond to events that occur in real-time. In this architecture, components of the application are loosely coupled, which means that changes to one component do not require changes to all the other components. This makes it easier to maintain and scale the application. However, it is more complex to implement and deploy. In classic three-tier applications, the core of the system is the database. In EDA, the focus shifts to events and how they flow through the system. This shift in focus allows for a complete change in the approach to designing applications and solving the aforementioned problems.
<center>

Figure 3: Event-driven architecture
</center>

Most companies are going through a phase of "digital transformation" accompanied by wild demands. Because of the complexity of these requirements, engineers have to learn new approaches to software design, which include, among other things, loosening the interconnectivity of services with each other and reducing the cost of service maintenance. EDA is one possible solution to these problems, but not the only one.

### 1.3. What are the differences between System architecture and Software architecture

|№|System Architecture|Software Architecture|
|-----|------|--------|
|1|System architecture is a conceptual model that describes the structure and behavior of multiple components and subsystems|Software architecture refers to the process of creating high level structure of a software system.|
|2|It focuses on the entire system|Where as software architecture focuses on the components|
|3|Various types of system architectures|Various software architecture patterns|
|4|It helps to define low level infrastructure of a software|It helps to define high level infrastructure of a software|
|5|It defines structure, behavior and view of a system|It defines the solutions to meet technical and business requirements|

### 1.4. Differentiate between the following in the context of software architecture and provide examples;
* #### Software correctness and Software robustness
In the context of software architecture, *software correctness* refers to the degree to which software meets its specification or meets user requirements. Examples include the successful storage of user data in a database by a web application or the accurate calculation and application of discounts in an e-commerce platform.
On the other hand, **software reliability(robustness)** refers to its ability to remain stable and perform well even under unexpected or exceptional conditions, such as high traffic or unexpected input data. Examples include implementing proper error handling to prevent the application from crashing when a user enters invalid data, or ensuring that a website remains up and running even during periods of high traffic, such as during Black Friday sales.
* #### Topic & queue
In software architecture, a **topic** can refer to a specific area or domain of functionality within a system. For example, in a social media platform, topics could include user profiles, messaging, and newsfeeds. On the other hand, a **queue** can be used to manage and prioritize tasks or events within a system. A queue can be utilized in an e-commerce platform as a means to efficiently handle orders. Each order would be placed in the queue and processed accordingly in the exact sequence it was received.

* #### Architecture & design
**Architecture and design** are two different but interrelated aspects of software development. Architecture is the overall structure and organization of a system, including its components and their interrelationships. Design, in turn, is concerned with the specific details and decisions related to the implementation of individual functions or components of the system.
*For example*, let's say we are building an e-commerce platform. Architecture involves defining the overall structure of the platform, such as the separation of front-end and back-end components, the database schema, and the APIs that will be used to communicate between components. Design involves working out the specific details of the platform, such as the layout of product pages, shopping cart functionality, and the design of the checkout process.
Thus, architecture is the big picture, and design is the details of realizing that big picture.

* #### User, primary stakeholder and secondary stakeholder

A **user** is anyone who interacts directly with a system or product, such as a website or software application. For example, a social network user is a person who creates an account, posts content, and interacts with other users.
A **key** **stakeholder** is a person or group of people who have a strong personal or financial interest in the success of the system or product. For example, in the case of an e-commerce platform, primary stakeholders might include customers, investors, and employees.
**Secondary** **stakeholders** are individuals or groups who have an interest in the system or product without being directly involved in its development or use. For example, regulators can be considered secondary stakeholders in financial software. They have an interest in ensuring that the application complies with applicable laws and regulations.
When developing software, it is very important to consider the needs and perspectives of all stakeholders. Such an approach not only effectively addresses the needs of users and stakeholders, but also ensures compliance with relevant laws and regulations.
* #### Cohesion & coupling

**Cohesion** is the degree to which the elements of a module or component are related to each other. A high degree of cohesion means that the elements of a module or component are closely related and contribute to a single, well-defined goal. For example, in a shopping cart module, all elements (such as add-to-cart buttons, quantity of items, and checkout buttons) are linked for a single purpose - to manage the items the user wants to purchase.

**Coupling** refers to the degree to which one module or component is dependent on another. A high degree of coupling means that changing one module or component may require changes to other modules or components. This can make the system difficult to maintain and scale. For example, if a module responsible for user authentication is tightly coupled with a module responsible for generating invoices, a change to the authentication module may require changes to the invoice generation module, even if the two modules are not directly linked.
Thus, high coupling and low coupling are desirable qualities in software architecture because they can lead to a more maintainable and scalable system.

<center>

### Task 2

</center>

### 2.1. List and explain the key concepts of Object-Oriented programming
Object-oriented programming is a programming paradigm based on the concept of objects that can contain data and code to manipulate that data. Here are some key concepts of object-oriented programming:

- **Encapsulation**: This refers to the practice of hiding data within an object and revealing it only through a set of public methods. This prevents inadvertent changes to the data and simplifies code maintenance.
- **Abstraction**: This refers to the practice of creating simplified interfaces for complex systems. In object-oriented programming, this is often accomplished through the use of abstract classes or interfaces.
- **Inheritance**: This is the ability of one class to inherit the properties and methods of another class. This reduces code duplication and simplifies code maintenance.
- **Polymorphism**: It is the ability of objects to take different forms. In object-oriented programming, this is often achieved through the use of interfaces or abstract classes.

### 2.2 What is an architectural view? Explain characteristics of architecture patterns in pattern based

An architectural view is a way of looking at a software system from a particular perspective or level of abstraction. Views can help to break down complex systems into smaller, more manageable pieces, and can provide a way to communicate different aspects of the system to different stakeholders.
Characteristics of architecture patterns in pattern-based software design include a focus on modularity and reusability, as well as an emphasis on defining clear interfaces between components. Patterns are often used to solve recurring problems in software architecture, and can help to ensure that a system is flexible, maintainable, and scalable. Pattern-based software design also often involves the use of abstraction and encapsulation to create clean, well-organized code that is easy to understand and modify.

### 2.3 Which are the main approaches to describing a software architecture? List and explain with sample diagrams
There are several approaches to describing a software architecture, but here are three of the main ones:
* **Box-and-Arrow Diagrams**: This is a simple but effective way to represent the high-level structure of a software system. In a box-and-arrow diagram, the system is represented as a set of boxes, with each box representing a component or module within the system. The boxes are connected by arrows that represent the flow of data or control between the components. Here is an example of a box-and-arrow diagram for a simple e-commerce platform:

<center>

Figure 4 : Box-and-Arrow Diagram
</center>

In this diagram, each block represents a component of the e-commerce platform, such as the user interface, product catalog, shopping cart, and checkout process. The arrows indicate the data or control flows between the components, e.g., the user adds items to the shopping cart, the shopping cart interacts with the checkout component, and the payment component processes the user's payment information.

* **Layered Architecture Diagrams**: This approach is useful for representing systems that have multiple layers of abstraction. In a layered architecture diagram, the system is represented as a set of layers, with each layer representing a level of abstraction within the system. Each layer is typically responsible for a specific set of tasks or operations, and communicates with other layers through well-defined interfaces. Here is an example of a layered architecture diagram for a simple web application:
<center>

Figure 5: Layered Architecture Diagram
</center>

In this diagram, a web application is divided into three layers: presentation, business, and data. The presentation layer is responsible for interacting with the user and displaying the user interface, while the business layer is responsible for implementing the application logic and handling user input. The data layer is responsible for interacting with the database and managing data storage. Each layer interacts with the layer above or below it through well-defined interfaces.

* **Component-and-Connector Diagrams**: This approach is useful for representing systems that are composed of multiple interacting components. In a component-and-connector diagram, the system is represented as a collection of components, with each component representing a distinct piece of functionality within the system. The components are connected by connectors, which represent the interactions or dependencies between the components. Here is an example of a component-and-connector diagram for a simple messaging system:
<center>

Figure 6: Component-and-Connector Diagram
</center>

In this diagram, the messaging system is composed of two components: the client and the server. The client component is responsible for sending messages, while the server component is responsible for receiving messages. The message sender and receiver components are connected to the client and server components through connectors that represent the flow of messages between the components.

### 2.4 Provide the advantages and disadvantages of the main approaches explained in question 2.3

| Diagram Type | Advantages | Disadvantages |
| --- | --- | --- |
| **Box-and-Arrow** | Simple and easy to understand | Effective for illustrating high-level system structure and flow |
| | Limited in terms of detail and granularity | Not ideal for complex systems with many components and relationships |
| **Layered Architecture** | Effective for representing systems with multiple levels of abstraction | Can provide a clear separation of concerns between layers |
| | May not be suitable for systems that do not have a clear separation of concerns | Can become complex and difficult to understand for very large systems |
| **Component-and-Connector** | Effective for representing complex systems with many components and relationships | Can show both structural and behavioral aspects of a system |
| | Can become very complex and difficult to understand for very large systems | May not be suitable for systems with a simple structure or limited components |