4.0 - Architectural Styles and Patterns.pdf

Architectural Styles and Patterns Unit 4 CC15 Systems Integration and Architecture Table of Contents Defining Architectural Styles and Patterns Case Study: Mud to Structure Layers Pipes and Filters Blackboard Defining Architectural Styles and Patterns Archi...

Architectural Styles and Patterns Unit 4 CC15 Systems Integration and Architecture Table of Contents Defining Architectural Styles and Patterns Case Study: Mud to Structure Layers Pipes and Filters Blackboard Defining Architectural Styles and Patterns Architectural Styles and Patterns Understanding Architectural Styles Architectural styles are a set of principles which shape an application. It defines an abstract framework for a system. It provides a list of components and connectors for a system with rules on how they are used. It also describes a particular way to configure a collection of components and connectors. Understanding Architectural Styles Each architectural style describes a system category that encompasses the following: A set of component types which perform a required function A set of connectors Semantic constraints which define how components can be integrated to form the system A topological layout of the components indicating their runtime interrelationships Types of Architectural Styles There are three categories of architectural styles which will be covered in future topics: Distributed Systems Interactive Systems Adaptive Systems Understanding Architectural Patterns Architectural Patterns are blueprints of a particular software, which looks at how a system is structured. It looks at how the layers and modules of the software are set up. It elaborates on the interaction between the different components of the given system. Types of Architectural Patterns We will be looking at a commonly used architectural pattern – Mud to Structure. This pattern, by its nature, is composed on smaller patterns which define its components. Case Study: Mud to Structure Architectural Styles and Patterns Defining Mud to Structure Mud to Structure breaks down a large system into small parts. The concept behind this is a system usually has several large components which can be broken down. These components each have small components and those components have smaller components and so on. We can then group similar parts together into layers. Defining Mud to Structure We have many components in one layer, which then has dependencies in another layer. We map out the connections between layers and components. Components of Mud to Structure These types of structures have three parts that define the mud to structure model: Layers Pipes and Filters Blackboard Layers Architectural Styles and Patterns Layers Layers help to structure applications that can be decomposed into groups of subtasks. Each group of subtasks is at a particular level of abstraction. Each layer is a client of the lower layer. Each layer provides services to the upper layer. 2-Tier Architecture The 2-Tier Architecture is based on a client-server machine. In this architecture, applications on the client-side interact directly with the database present at the server-side. The two parts of the 2-Tier Architecture are as follows: Client tier Data tier 2-Tier Architecture The application on the client tier establishes a connection with the server in order to communicate with the data layer. The data tier is responsible for providing query processing and transaction management functionality. 2-Tier Architecture When creating the 2-tier architecture, the client tier contains the codes for interfacing with the user and for saving data in the database server. 2-Tier Architecture When creating the 2-tier architecture, the data tier handles data management, and consists of data storage and methods of manipulating data. 2-Tier Architecture Here is another visual example of the 2-Tier Architecture: n-Tier Architecture A n-Tier Architecture refers to a software architecture which typically has three (or more) given layers: Presentation tier Business tier Data tier n-Tier Architecture In this architecture, the client does not directly communicate with the database server. The presentation tier interacts with an application server which further communicates with the data tier. The data tier contains the database server that is used for query processing and transaction management. The business tier serves as a medium of the exchange for data between the server and client. n-Tier Architecture The presentation tier is typically the first tier, like the two-tier architecture. n-Tier Architecture The business tier resides on the second tier. It handles the portion of the business logic that does not require the functionality that the database server provides. n-Tier Architecture The data tier is typically on the third tier, where the database server serves the data. The database server typically uses stored procedures to handle some of the business logic. n-Tier Architecture Here is another visual example of the n-Tier Architecture: Pipes and Filters Architectural Styles and Patterns Pipes and Filters Pipes and Filters is an architectural design pattern that allows for stream/asynchronous processing. This type of pattern is best for large processes that can be broken down into multiple steps. This pattern has two components: Pipes Filters Pipes and Filters Filters receive messages on an inbound pipe, processes the message, the publishes the results to an outbound pipe. Pipes and Filters Pipes connect one filter to the next, sending output messages from one filter to the next. Pipes and Filters The pattern of interaction in a pipe-and-filter pattern is characterized by successive streams of data. Data flows in one direction. Data starts at the source, arrives at a filter’s input ports, then is passed via its output ports to the next filter. Data then ends up at the data target or data sink. Pipes and Filters A single filter can consume data from or produce data to one or more ports. They can also run concurrently and are not dependent. The output of one filter is the input of another, which is why the order is important. Pipes and Filters Here is another example of how pipes and filters can be utilized. In this example, the following system processes data using a monolithic approach. Pipes and Filters We can break down the processing that is required for each data stream into a set of separate filters. An example of this is seen on the right side. Pipes and Filters Here is another visual example of the pipes and filter architecture: Pipes and Filters Pipes and Filters in Unix/Linux The concepts of pipes and filters is commonly seen on the Unix/Linux operating system. You can connect two or more commands together in Unix/Linux. Unix/Linux commands can be used to form pipes and filters via code. Pipes and Filters Pipes and Filters in Unix/Linux Let us look at an example, a file “sample” has seven items within that can be processed. Let’s say we would like to get the items which do not contain the lowercase ‘a’, and the result should be in reverse order. Pipes and Filters Pipes and Filters in Unix/Linux We can use a set of commands to pipe and filter the given data. cat sample This prints out the contents of our file grep –v a This prints out the reverse of all items that do not contain the lowercase “a”. sort –r This sorts the data in reverse. Blackboard Architectural Styles and Patterns Blackboard The blackboard architectural pattern is useful for problems with no deterministic solution. This pattern is used for subsystems that share data but not processes. Components can generate or write data Components can use or read data Blackboard The blackboard architectural style is composed of three main components: Blackboard Controller Multiple Knowledge Sources Blackboard The blackboard manages central data and updates the knowledge sources. All components have access to the blackboard. Blackboard The controller monitors the blackboard and moderates the knowledge sources. Specialized modules with their own representation. Blackboard The knowledge sources are specialized workers that have their own representation of the problem and blackboard. Components may produce new data objects that are added to the blackboard. Blackboard The blackboard is a place that holds global data. We can then inspect and update the blackboard. A knowledge source can update the blackboard, and there can be multiple sources of knowledge. The control works with multiple sources and interacts with the sources and the blackboard. Blackboard Here is another visual example of a blackboard architectural pattern: References https://learn.microsoft.com/en-us/azure/architecture/patterns/pipes-and- filters https://www.oreilly.com/library/view/software-architecture- with/9781786468529/ch08s04.html https://syedhasan010.medium.com/pipe-and-filter-architecture- bd7babdb908 https://www.modernescpp.com/index.php/pipes-and-filters https://www.ibm.com/docs/en/db2-for-zos/11?topic=environment- architectural-characteristics-web-based-applications https://medium.com/@fleviankanaiza/two-tier-three-tier-architecture- 8b02536d3482 https://towardsdatascience.com/10-common-software-architectural- patterns-in-a-nutshell-a0b47a1e9013