Architectural DesignPatterns

Download as pdf or txt
Download as pdf or txt
You are on page 1of 33
At a glance
Powered by AI
The key takeaways are that architectural patterns provide general reusable solutions to common problems in software architecture at a higher level than design patterns. The document discusses categories of patterns, examples of layer and pipes/filters patterns, and distributed systems patterns.

The three categories of architectural patterns discussed are: from mud to structure, distributed systems, and interactive systems.

A layered system decomposes tasks into cooperating subtasks with each layer building on the one below it. A pipes and filters system processes a stream of data with each processing step encapsulated in a filter component.

Architectural Design

&
Patterns
Members:
Abdul Manan 1420 Areeba Riaz 1439
Junaid Majeed 1428 Allah Ditta 1419
Architectural Pattern
• An architectural pattern is a general, reusable solution to a
commonly occurring problem in software architecture.
• Architectural patterns are similar to software design pattern but
have a broader scope.
• Design patterns are medium-scale tactics that flesh out some of the
structure and behavior of entities and their relationships.
• Architectural patterns are high-level strategies that concerns large-
scale components, the global properties and mechanisms of a
system.
• The architectural patterns address various issues in software
engineering, such as computer hardware performance
limitations, high availability and minimization of a business risk.
Categories of architectural patterns

• From mud to structure


• Patterns: Layers, “Pipes and filters”
• Distributed systems
• Patterns: Broker, Master-Slave
• Interactive systems
• Patterns: Model-View-Controller (MVC) ,MVP,MVVM

Architectural patterns 3
Architectural Pattern - Layers

• Decompose overall system task into cooperating


subtasks Examples
• TCP/IP, and other protocol stacks
• Java application, JVM, OS, physical machine
• Upper layer asks lower layer for service

Architectural patterns 4
Architectural Pattern - Pipes and
filters
• System process a stream of data.
• Each processing step is encapsulated in a filter component.
• Examples
• A shell in an operating system, like Linux/UNIX or MS-DOS
• find “a” data.txt | sort | more
• Find all lines with “a” in data.txt | sort the lines | show the lines, one screen at a
time
• Compilation of a Java program
• Lexical analysis | syntax analysis | semantic analysis | code generation
• Reuse of filter components
5
Distributed systems

• A layered system can be distributed


• Each layer running on a separate computer
• Called “multi-tiered” system
• A “pipes and filters” system can be distributed
• Each filter running on a separate computer
• Pipes are network connections

6
Architectural Pattern - Broker
• Coordinates communication between distributed components
• Broker features
• Locate servers
• Forward messages
• Examples
• CORBA
• Common Object Request Broker Architecture
• an architecture that enables pieces of programs, called objects, to
communicate with one another regardless of what programming
language they were written in or what operating system they're running on.
CORBA was developed by an industry consortium known as the Object
Management Group (OMG).
• Some chat / messenger systems
7
Broker, consequences
• Benefits
• Location transparency
• Clients do not need to know where servers are.
• Servers can be moved to other computers.
• Changeability and extensibility
• Servers can be changed
• Keep the same interface
• Reusability
• Components can be reused in other application
• Liabilities
• Efficiency
• Fault tolerance
• Broker is not working => nothing is working
8
Architectural Pattern
– Master-Slave
• Divide and conquer
• Master functions
• Split work
• Call slaves
• Combine results
• Examples
• Parallel processing
• Fault tolerance
• Computational accuracy
9
Master-Slave, consequences

• Benefits
• Faster computation
• Split the problem over threads and machines.
• Robustness
• Slaves can be duplicated

10
Interactive systems
• Interaction with the user
• Through graphical user interfaces
• System responds to events (user inputs)
• Functional core of the system must be kept independent
of the user interface
• You must be able to add a new user interface to the system.
• A single system can have many user interfaces
• PC interface
• Web interface
• Mobil phone interface
11
Interactive System Architectural
Patterns
• There are the followings architectural patterns:
• MVC – Model View Controller
• MVP – Model View Presenter
• MVVM – Model View View-Model
MVC - Model View Controller
• Model View Controller or MVC as it is popularly called, is a
design pattern for developing web applications. A Model View
Controller pattern is made up of the following three parts:
• Model - The lowest level of the pattern which is responsible for
maintaining data.
• View - This is responsible for displaying all or a portion of the data
to the user.
• Controller - Software Code that controls the interactions between the
Model and View.
• MVC is popular as it separates the application logic from the
user interface layer and supports separation of concerns.
The Model
• The model is responsible for managing the data of the
application.
• It responds to the request from the view and it also responds
to instructions from the controller to update itself.

The View
• A presentation of data in a particular format, produced by
a controller's decision to present the data.
• They are script based templating systems like JSP, ASP,
PHP and very easy to integrate with AJAX technology.
The Controller
• The controller is responsible for responding to user input and
perform interactions on the data model objects.
• The controller receives the input, it validates the input and then
performs the business operation that modifies the state of the
data model.
• Struts2 is a MVC based framework.
• Apache Struts 2 is an open-source web application framework
for developing Java EE web applications. It uses and extends
the Java Servlet API to encourage developers to adopt a model–
view–controller (MVC) architecture
Implementation

• We are going to create a Student object acting as a


model.StudentView will be a view class which can
print student details on console.
• StudentController is the controller class responsible to
store data in Student object and update
viewStudentView accordingly.
• MVCPatternDemo, our demo class, will
use StudentController to demonstrate use of MVC
pattern.
Sequence Diagram
MVP – Model View Presenter

• This pattern is similar to MVC pattern in which


controller has been replaced by the presenter.
• This design pattern splits an application into three
main aspects:
• Model
• View
• Presenter
• Model and View are same as MVC.
The Presenter
• The Presenter is responsible for handling all UI events on
behalf of the view.
• This receive input from users via the View, then process the
user's data with the help of Model and passing the results back
to the View.
• view and presenter communicate to each other’s by an
interface.
• Also, presenter does not manage the incoming request traffic
as controller.
• There is one-to-one relationship between View and Presenter
means one View is mapped to only one Presenter.
Sequence Diagram
MVVM – Model View View-Model

• This design pattern splits an application into three


main aspects:
• Model
• View
• View Model
• Model and View are same as MVC.
The View Model

• The View Model is responsible for showing methods,


commands, and other properties that helps to maintain
the state of the view, manipulate the model as the result
of actions on the view, and activate events in the view
itself.
• There is many-to-one relationship between View and
ViewModel means many View can be mapped to one
ViewModel.
• the MVVM pattern allows your code to be consistently
tested through unit testing.
The View Model
• A ViewModel is a model for a view in the application as shown
by its name. It has a collection which contain the data from the
model currently needed for the view.
• The view binds to properties on a ViewModel, which, in turn,
exposes data contained in model objects and other state specific
to the view. The bindings between view and ViewModel are
simple to construct because a ViewModel object is set as the
Data Context of a view. If property values in the ViewModel
change, those new values automatically propagate to the view
via data binding. When the user clicks a button in the View, a
command on the ViewModel executes to perform the requested
action.
Sequence Diagram
Summary

You might also like