University of Jordan

Computer Engineering
Department
Software Engineering and Ethics
Dr. Andraws Swidan
Khaled Sharif
0115948
Homework #4
Software Design Patterns

Page 1 of 5

Software Design Patterns

A brief overlook of the five main software design
patterns typically used in software engineering

Model-View-Controller
The Model-View-Controller design pattern assigns objects in an application one
of three roles: model, view, or controller. The pattern defines not only the roles
objects play in the application, it defines the way objects communicate with
each other. Each of the three types of objects is separated from the others by
abstract boundaries and communicates with objects of the other types across
those boundaries. The collection of objects of a certain MVC type in an
application is sometimes referred to as a layer.
The central component of the design pattern, the model, captures the behavior
of the application in terms of its problem domain, independent of the user
interface. The model directly manages the data, logic and rules of the
application. A view can be any output representation of information, such as a
chart or a diagram; multiple views of the same information are possible, such
as a bar chart for management and a tabular view for accountants. The third
part, the controller, accepts input and converts it to commands for the model
or view.

Layered Architecture
Layered architecture focuses on the grouping of related functionality within an
application into distinct layers that are stacked vertically on top of each other.
Functionality within each layer is related by a common role or responsibility.
Communication between layers is explicit and loosely coupled. Layering an
application appropriately helps to support a strong separation of concerns, and
therefore supports flexibility and maintainability.
The layered architectural style has been described as an inverted pyramid of
reuse where each layer aggregates the responsibilities and abstractions of the
layer directly beneath it. With strict layering, components in one layer can
Page 2 of 5

interact only with components in the same layer or with components from the
layer directly below it. More relaxed layering allows components in a layer to
interact with components in the same layer or with components in any lower
layer.

Repository
The repository design pattern mediates between the domain and data mapping
layers, acting like an in-memory domain object collection. Client objects
construct query specifications declaratively and submit them to repository for
satisfaction. Objects can be added to and removed from the repository, as they
can from a simple collection of objects, and the mapping code encapsulated by
the repository will carry out the appropriate operations behind the scenes.
Conceptually, a repository encapsulates the set of objects persisted in a data
store and the operations performed over them, providing a more objectoriented view of the persistence layer. Repository also supports the objective of
achieving a clean separation and one-way dependency between the domain
and data mapping layers.

Page 3 of 5

Client-Server
The clientserver model partitions tasks or workloads between the providers of
a resource or service, called servers, and service requesters, called clients. In
the model, clients and servers communicate over a computer network on
separate hardware, but both client and server may reside in the same system.
A server host runs one or more server programs which share their resources
with clients. A client does not share any of its resources, but requests a server's
content or service function. Clients therefore initiate communication sessions
with servers which await incoming requests.

Pipe and Filter

In this design pattern, the application is organized as a series of computational
tasks that correspond to filters, connected by dependencies that correspond to
pipes. The tasks can be seen as vertices in a task graph, and the pipes carrying
information from one task to another can be seen as a directed edge in the task
graph.
There are three main issues when dealing with the pipe-filter design pattern.
The first is complexity: the increased flexibility that this pattern provides can
also introduce complexity, especially if the filters in a pipeline are distributed
across different servers. The second is reliability: the designer must use an
infrastructure that ensures data flowing between filters in a pipeline will not be
lost. The third is idempotency: if a filter in a pipeline fails after receiving a
message and the work is rescheduled to another instance of the filter, part of
the work may have already been completed. If this work updates some aspect
of the global state, the same update could be repeated.

Page 4 of 5

Page 5 of 5