8/25/2019 Computer Science Department, TUC-N

SOFTWARE DESIGN
Architectural patterns
8/25/2019 Computer Science Department, TUC-N

Content
• Architectural Patterns
• Layers
• Client-Server
• Event-driven
• Broker
• Mediator
• MVC (and variants)
• Service-based
• SOA
• Microservices
• Space-based (Cloud)
8/25/2019 Computer Science Department, TUC-N

References
• Mark Richards, Software Architecture Patterns, O’Reilly, 2015 [SAP]
• Mark Richards, Microservices vs. Service-Oriented Architecture O’Reilly,
2016
• David Patterson, Armando Fox, Engineering Long-Lasting Software: An
Agile Approach Using SaaS and Cloud Computing, Alpha Ed.[Patterson]
• Taylor, R., Medvidovic, N., Dashofy, E., Software Architecture:
Foundations, Theory, and Practice, 2010, Wiley [Taylor]
• F. Buschmann et. al, PATTERN-ORIENTED SOFTWARE
ARCHITECTURE: A System of Patterns, Wiley&Sons, 2001.[POSA]
• Martin Fowler et. al, Patterns of Enterprise Application Architecture,
Addison Wesley, 2003 [Fowler]
• O. Shelest, MVC, MVP, MVVM design patterns,
http://www.codeproject.com/KB/architecture/MVC_MVP_MVVM_design.as
px
http://www.tinmegali.com/en/model-view-presenter-mvp-in-android-part-2/
• Univ. of Aarhus Course Materials
• Univ. of Utrecht Course Materials
8/25/2019 Computer Science Department, TUC-N

Architectural Patterns
• Definition
• An architectural pattern expresses a fundamental structural
organization schema for software systems. It provides a set of
predefined subsystems, specifies their responsibilities, and
includes rules and guidelines for organizing the relationships
between them.
[POSA, vol.1]

• Different books present different taxonomies of patterns

8/25/2019 Computer Science Department, TUC-N

Structural AP

• From Mud to Structure

• Direct mapping Requirements -> Architecture?

• Problems: non-functional qualities like portability, stability,

maintainability, understandability…
8/25/2019 Computer Science Department, TUC-N

Layers
• Definition
• The Layers architectural pattern helps to structure
applications that can be decomposed into groups of
subtasks in which each group of subtasks is at a
particular level of abstraction.

• Example
• Networking: OSI 7-Layer Model
8/25/2019 Computer Science Department, TUC-N

Layers AP
• Addressed problems
• High-level and low-level operations
• High-level operations rely on low-level ones
Vertical structuring

• Several operations on the same level on abstraction but

highly independent
Horizontal structuring
8/25/2019 Computer Science Department, TUC-N

Constraints
• Late source code changes should not ripple
through the system.

• Interfaces should be stable and may even be

prescribed by a standards body.

• Parts of the system should be exchangeable.

• It may be necessary to build other systems at a

later date with the same low-level issues as the
system you are currently designing.
 8/25/2019 Computer Science Department, TUC-N

Constraints [2]

• Similar responsibilities should be grouped to

help understandability and maintainability.

• There is no 'standard' component granularity.

• Complex components need further decomposition.

• The system will be built by a team of programmers,

and work has to be subdivided along clear
boundaries.
8/25/2019 Computer Science Department, TUC-N

Key concepts
• Closed layers
• Layers of isolation:
changes made in one layer of the architecture don’t impact
components in other layers
8/25/2019 Computer Science Department, TUC-N

Variants
• Relaxed layered system
 8/25/2019 Computer Science Department, TUC-N

Example
Customer Screen:
• Java Server Faces
• ASP (MS)
Customer Delegate:
• managed bean component
Customer Object:
• Local Spring Bean
• Remote EJB3 component
• C# (MS)
DAOs:
• POJOs
• MyBatis XML Mapper files
• Objects encapsulating raw JDBC calls or Hibernate queries
• ADO (MS)
8/25/2019 Computer Science Department, TUC-N

Considerations
• Sink-hole anti-pattern
• requests flow through multiple layers of the architecture as simple
pass-through processing with little or no logic performed within
each layer.
Non functional req. Rating

Overall agility Low

Ease of deployment Low

Testability High

Performance Low

Scalability Low

Ease of development High

8/25/2019 Computer Science Department, TUC-N

Client-Server
• Components are clients and servers
• Servers do not know number or identities of clients
• Clients know server’s identity
8/25/2019 Computer Science Department, TUC-N

Types of servers and clients

• Servers
• Iterative (UDP-based servers, ex. Internet services like echo,
daytime)
• Concurrent (TCP-based servers, ex. HTTP, telnet, and FTP)
• Thread-per-client
• Thread pool

• Clients
• Thin
• Fat
8/25/2019 Computer Science Department, TUC-N

Layers vs. tiers

• Layers – logical (ex. presentation, business logic, data
access)
• Tiers – physical
8/25/2019 Computer Science Department, TUC-N

Considerations
 8/25/2019 Computer Science Department, TUC-N

Peer-to-Peer
• State and behavior are distributed among peers which
can act as either clients or servers.
• Peers: independent components, having their own
state and control thread.
• Connectors: Network protocols, often custom.
• Data Elements: Network messages
 8/25/2019 Computer Science Department, TUC-N

Peer-to-Peer [2]
• Topology: Network (may have redundant connections
between peers); can vary arbitrarily and dynamically
• Supports decentralized computing with flow of control and
resources distributed among peers.
• Highly robust in the face of failure of any given node.
• Scalable in terms of access to resources and computing
power.
• Drawbacks:
• Poor security
• Nodes with shared resources have poor performance
8/25/2019 Computer Science Department, TUC-N

Event-driven (distributed) architectures

• (Distributed) asynchronous architecture pattern
• Highly scalable applications
• Highly adaptable by integrating highly decoupled, single-
purpose event processing components that
asynchronously receive and process events

• 2 main topologies
• Broker
• Mediator
8/25/2019 Computer Science Department, TUC-N

Broker
• Definition
• The Broker architectural pattern can be used to structure
distributed software systems with decoupled components that
interact by remote service invocations. A broker component is
responsible for coordinating communication.
• Example
• SOA
8/25/2019 Computer Science Department, TUC-N

Broker
• Context
• The environment is a distributed and possibly
heterogeneous system with independent, cooperating
components.
• Problems
• System = set of decoupled and inter-operating
components
• Inter-process communication
• Services for adding, removing, exchanging, activating
and locating components are also needed.
8/25/2019 Computer Science Department, TUC-N

Forces
• Components should be able to access services provided
by others through remote, location-transparent service
invocations.
• You need to exchange, add, or remove components at
run-time.
• The architecture should hide system- and implementation-
specific details from the users of components and
services.
8/25/2019 Computer Science Department, TUC-N

Non-distributed system [MSDN]

8/25/2019 Computer Science Department, TUC-N

Distributed System [MSDN]

8/25/2019 Computer Science Department, TUC-N

Distributed System – Problems?

8/25/2019 Computer Science Department, TUC-N

Solution
8/25/2019 Computer Science Department, TUC-N

Scenario I
8/25/2019 Computer Science Department, TUC-N

Scenario II
8/25/2019 Computer Science Department, TUC-N

Scenario III
8/25/2019 Computer Science Department, TUC-N

Event-driven perspective
8/25/2019 Computer Science Department, TUC-N

Consequences
• Benefits
• Location transparency
• Changeability and extensibility of components
• Portability of a Broker System
• Interoperability between Broker Systems
• Reusability

• Liabilities
• Reliability – remote process availability, lack of responsiveness,
broker reconnection
• Lack of atomic transactions for a single business process
8/25/2019 Computer Science Department, TUC-N

Considerations
8/25/2019 Computer Science Department, TUC-N

Mediator
• for events that have multiple steps and require some level
of orchestration to process the event
8/25/2019 Computer Science Department, TUC-N

Components
• Event queue (hosts initial events)
• Message queue
• Web service endpoint
• Events
• Initial
• Processing
• Event channel (passes processing events)
• Message queue
• Message topic
• Event processor
• self-contained, independent, highly decoupled business logic
components
 8/25/2019 Computer Science Department, TUC-N

• Event mediator
• open source integration hubs such as Spring Integration, Apache
Camel, or Mule ESB
• BPEL (business process execution language) coupled with a BPEL
engine (ex. Apache ODE)
• business process manager (BPM) (ex. jBPM)
8/25/2019 Computer Science Department, TUC-N

Interactive Systems
• Model-View-Controller
• The Model-View-Controller architectural pattern (MVC) divides an
interactive application into three components. The Model contains
the core functionality and data. Views display information to the
user. Controllers handle user input. Views and controllers together
comprise the user interface.

• Many existing frameworks: JavaServer Faces (JSF),

Struts, CakePHP, Django, Ruby on Rails, ...
8/25/2019 Computer Science Department, TUC-N

MVC
• Example
• Any Information System

• Context
• Interactive applications with a flexible human-computer interface.

• Problem
• User interfaces are especially prone to change requests.
• Different users place conflicting requirements on the user interface.
8/25/2019 Computer Science Department, TUC-N

MVC
• Constraints
• The same information is presented differently in different windows,
for example, in a bar or pie chart.

• The display and behavior of the application must reflect data

manipulations immediately.

• Changes to the user interface should be easy, and even possible at

run-time.

• Supporting different 'look and feel' standards or porting the user

interface should not affect code in the core of the application.
8/25/2019 Computer Science Department, TUC-N

MVC
• Solution
• 3 areas: handle input, processing, output

• The Model component encapsulates core data and functionality

(processing).

• View components display information to the user. A view obtains

the data from the model (output).

• Each view has an associated controller component. Controllers

handle input.
8/25/2019 Computer Science Department, TUC-N

MVC Structure
8/25/2019 Computer Science Department, TUC-N

MVC more detailed

8/25/2019 Computer Science Department, TUC-N

The Model
• The model encapsulates and manipulates the domain
data to be rendered
• The model has no idea how to display the information is
has nor does it interact with the user or receive any user
input
• The model encapsulates the functionality necessary to
manipulate, obtain, and deliver that data to others,
independent of any user interface or any user input device
8/25/2019 Computer Science Department, TUC-N

The View
• A View is a specific visual rendering of the information
contained in the model.
• A view may be graphical or text based
• Multiple views may present multiple renditions of the data
in the model
• Each view is a dependent of a model
• When the model changes, all dependent views are
updated
8/25/2019 Computer Science Department, TUC-N

The Controller
• Controllers handle user input. They “listen” for user
direction, and handle requests using the model and views
• Controllers often watch mouse events and keyboard
events
• The controller allows the decoupling of the model and its
views, allowing views to simply render data and models to
simply encapsulate data
• Controllers are “paired up” with collections of view types,
so that a “pie graph” view would be associated with its
own “pie graph” controller, etc.
• The behavior of the controller is dependent upon the
state of the model
8/25/2019 Computer Science Department, TUC-N

How does this work?

• The model has a list of views it supports

• Each view has a reference to its model, as well as its

supporting controller

• Each controller has a reference to the view it controls, as

well as to the model the view is based on. However,
models know nothing about controllers.

• On user input, the controller notifies the model which in

turn notifies its views of a change

• Changing a controller’s view will give a different look.

• Changing a view’s controller will give a different feel.
8/25/2019 Computer Science Department, TUC-N

Scenario I
8/25/2019 Computer Science Department, TUC-N

Scenario II
8/25/2019 Computer Science Department, TUC-N

Consequences
• Benefits
• Multiple views of the same model.
• Synchronized views.
• 'Pluggable' views and controllers
• Exchangeability of 'look and feel'.
• Framework potential.

• Liabilities
• Increased complexity.
• Potential for excessive number of updates.
• Intimate connection between view and controller.
• Close coupling of views and controllers to a model
• Inefficiency of data access in view.
• Inevitability of change to view and controller when porting.
8/25/2019 Computer Science Department, TUC-N

MVC in ASP.NET
8/25/2019 Computer Science Department, TUC-N

MVC Code
8/25/2019 Computer Science Department, TUC-N

MVP
 8/25/2019 Computer Science Department, TUC-N

Usage
• MVP vs MVC
• delegates more work to the Presenter and removes the Controller.
• Presenter class encapsulates the View’s state and commands. The
Presenter is the mediator between Model and View!
• View is separated from Model => better separation of concerns
• MVP in Android example –
take notes on a journal
8/25/2019 Computer Science Department, TUC-N

MVP Design • Presenter implements interface

PresenterOps
• View receives reference
from PresenterOps to
access Presenter
• Model implements interface ModelO
ps
• Presenter receives reference
from ModelOps to access Model
• Presenter implements RequiredPre
senterOps
• Model receives reference
from RequiredPresenterOps to
access Presenter
• View implements RequiredViewOps
• Presenter receives reference
from RequiredViewOps to
access View
8/25/2019 Computer Science Department, TUC-N

MVP Code
Android_MVP_code.txt
8/25/2019 Computer Science Department, TUC-N

MVVM
 8/25/2019 Computer Science Department, TUC-N

How it works
• View and ViewModel
• communicate via data-binding, method calls,
properties, events, and messages
• The viewmodel exposes not only models, but other
properties (such as state information, like the "is
busy" indicator) and commands
• The view handles its own UI events, then maps
them to the viewmodel via commands
• The models and properties on the viewmodel are
updated from the view via two-way databinding
• ViewModel and Model
• The viewmodel may expose the model directly, or
properties related to the model, for data-binding
• The viewmodel can contain interfaces to services,
configuration data, etc., in order to fetch and
manipulate the properties it exposes to the view
8/25/2019 Computer Science Department, TUC-N

MVVM Code Example

8/25/2019 Computer Science Department, TUC-N
8/25/2019 Computer Science Department, TUC-N

Food for thought…

Why I No Longer Use MVC Frameworks,
posted by Jean-Jacques Dubray on Feb 03, 2016