So in architectural analysis and design, we focus on understanding how a system should be organized in terms of subsystems, and we try to design the overall structure of the system. And the main structural components and the relationship between them identified it in terms of subsystems. So we've tried, so we focus on how to organize the subsystems together to form the entire system. And a subsystem encapsulates is content and provide services to other subsystems were innovates, and also a subsystem provides information hiding. And this is what we have covered before, since we have a large software system. And that's why we have to use divide and conquer wire and then chunk the large software systems into many smaller subsystems. And then we're going to handle one smaller sub system at the time, and each subsystem provides its own services veer and innovates. And each subsystem provides information hiding, that means you don't have to actually know how to implement that subsystem. You just need to know how to use that particular subsystem using the interstates. And usually non functional requirements are highly dependent on the system architecture. So how we arrange the subsystems together to form the entire system. And architectural analysis and design is an essential to for managing complexity. Because instead of thinking about the large software system, now we simply have to design and organize the subsystems together to form the entire system. Now, when we try to connect the subsystems together to form the entire system, the connections can be either closed layer or open layer. For closed layer, that means each layer can depend only on the layer immediately below it. And for open layer, that means each layer can depend on any layer below it, so let me show you some examples. So in this example, you can see that this green subsystem is connected to another subsystem which is immediately below it, so this is an example of a closed layer subsystem. And for this yellow one, you can see that it depends on another subsystem which is not immediately below it, so this is an example of an open layer subsystem. And usually within a system, we will have three to five subsystem layers in practice. And the partitions will organize subsystems in one layer to provide different services, and this results in peer to peer services within a layer. And partitioning, and also layering, will produce a system hierarchy. And you can see that some of the subsystems they are open layered, for example, this green one. And you will see that some of the subsystems, they are closed layered, for example, this one depends on another subsystem which is immediately below it. And some of the subsystems they are open layer for example, this one depends on another subsystem which is not immediately below it et cetera. And usually the top layers they are related to use innovates, okay? So somehow, and usually the top layers they are subsystems related to user interface. And the inner layers, they are more critical of systems which control the behavior of the software system, and we call them controllers. So based on all the non functional requirements that we have captured in our SOS, we can somehow come up with a hierarchy that we can use for building the system. If you want to achieve performance, then one architecture that we can use is to use a small number of subsystems to localize critical functions. Then when we try to perform some functionality within the system, we simply have to refer to a small number of subsystems. And if you want security, we can use a layered architecture with most critical subsystems in the most layer. And we can also make it close layer, so that if we want to access something critical, we have to go through multiple layers before we can go into the innermost layer to assess those most critical subsystems. And if you want safety, then you may want one subsystem or a small number of subsystems to localize safety related functions. If you want to make sure that your system is going to be always available, then you may include redundancy systems to allow replacement or update with those stopping the system. So now, what should we do if we want to achieve maintainability? Then we should use small and self contained subsystems that can be easily changed. That means if we want to change a particular functionality within the software system, we only have to touch one of the subsystems, but not the artists of systems, and that's going to make our system more maintainable. And we may also use some existing architectural pattern to design our software system. And an architectural pattern is going to specify how to organize and connect a set of software components together to form the entire system. And it is a blueprint for system organization that defines the software architecture of a system. And it includes the specification of how we decompose the system into different subsystems, and also global control flow, error handling policies, inter module component communication protocols, et cetera. And notice that most large sovereign system utilized several architectural patterns together in different parts of the system. And the first architectural pattern that we're going to talk about is multi layer architectural pattern. And this is what we have already covered, we're going to put subsystems in different layers, okay? And then we may connect the subsystems together using closed layered or open layered. And we may also use the repository architectural pattern. In the repository architectural pattern, we're going to have many clients, and then these clients, they will depend on a repository for data management. So if these clients they want to assess some data, it has to be done through this repository, this centralized repository. And this is the typical architectural pattern that we use for database management system. And the drawbacks of this pattern is that the repository can be a performance and modifiability bottle lag, right? Because many clients depends on this repository in order to retrieve and get some data. And there is a high company between the repository and the subsystems. Again, we may have many subsystems depending on this repository, then the repository may become the performance bottleneck for the entire system. And the next pattern that we're going to talk about is the client server pattern. In the client server pattern, we're going to have many clients, and then we have a server, and then underneath the server we're going to have a database server. And this is the typical pattern that we use for building web applications. Because when we talk about web applications, we may have many clients using for example their browsers to get something from a server. And the server will keep all the information within a database server, it may be free tier, that means we have client and server and database server or P to P. That means client they can communicate with each other directly in order to get some information. And the next pattern that we're going to cover is what we call the broker pattern. In the broker pattern, we will have a client that tries to assess something remotely. Then we have to implement a proxy on the client so that somehow when we try to get something remotely, it has to be assessed through this proxy. And then we have the broker which is going to handle the communication between the client and the remote object. And the remote object is going to store the information which is the information that the client wants to assess. And the good thing about this pattern is that when you try to assess something remotely, that request will be handled by the proxy, and the communication will be handled by the broker. So when the client tried to assess something remotely, it will be automatically done by the proxy and the broker. So somehow when you try to assess something remotely, it's going to be like assessing something locally, because all the things will be handled by the proxy and the broker. So these are some examples applications that utilize the broker pattern, and we can use the proxy design pattern to implement the broker architecture. And we will cover prosthetic design patterns in one of the upcoming lectures, and this is the transaction processing pattern. In this pattern, we have a subsystem to handle all the transactions, and then those transactions they will be fitted into a transaction dispatcher. Which will eventually dispatch these transactions into different handlers to process the transactions. And an example application that utilizes this transaction processing pattern is a database engine. Because within a database management system, we have many transactions. Then the DBMs is going to utilize this pattern to dispatch the transactions into different handlers to process the transactions. And the next pattern that we're going to cover is what we call the pipe and filter pattern. In this pattern, a stream of data is passed through a series of filters, and you have a series of images that you want to process. Then you may feed the first image into degree and subsystem to process something, okay? For example, converting the image into grayscale. Then after it's done, right? Then the first image will be passed into the second subsystem maybe for antialiasing. Then now, the first subsystem is not processing anything, then we can feed the second image into this green one. Now, the green one is processing the second image, and converting the image into grayscale, while the second subsystem is now doing antialiasing on the image et cetera. So that's why here we say that we try to do pipelining with a stream of data. If we are talking about image processing, then we can feed some image into a subsystem, after the processing is done, then we fit it into the next subsystem. And then after it's done, we fitted into another subsystem, so on and so forth, and this is what we call pipelining. And the good thing about pipelining is that each filter or each subsystem can handle some image concurrently. So that means difference of systems will be handling or processing different images at the same time. An example application that utilizes pipe and fielder pattern is the unique cell. And the last architectural pattern that we're going to cover today is what we call the MVC, the model view and controller pattern. And this is a very popular pattern that we can use to develop a system which involves some use interface, some data, and also some controllers. And when we talk about model, we are talking about subsystems that is going to handle data within the system. And if we are talking about view, we are talking about subsystems that handle the UI within the system. And if you are talking about controller, then they are the subsystems which control the behavior of the software system. And now, we split the large software systems into these three types of subsystems. Just because for example, if you want to modify the UI, then we simply have to modify the view subsystems, we don't have to touch the other two subsystems. Or if we want to modify data, then we simply have to modify the model subsystem without touching the other two subsystems et cetera. And this is the good thing about the MVC model, we try to separate the user interface layer from the other parts of the system. And we can use the observer design pattern to separate the model from the view. And we will cover the observer pattern in one of the upcoming lectures.
