Mata kuliah
Tahun
: T0144 – Advanced Topics in Software Engineering
: 2010
Pertemuan 09
Architectural Patterns
Learning Outcomes
Pada akhir pertemuan ini, diharapkan:
Mahasiswa dapat menjelaskan beberapa high level Architectural
Pattern yang biasa ditemui
3
Outline Material
•
•
Software Architecture
Patterns Category:
– Architectural
– Design
– Coding
•
Architectural Pattern Examples
– First cut : Layers Pattern
– Distributed Systems: Broker Pattern
– Interactive Systems: MVC Pattern
4
Software Architecture
• A description of the structure of the system
– Listing the software components involved,
– Documenting the externally visible properties of those components
– and explaining the relationships between them.
• The term also refers to documentation of a system's software
architecture.
• Documenting software architecture is useful for:
– facilitating communication
– documents early decisions about high-level design
– allows reuse of design components and patterns between projects
Patterns Category
• Architectural Pattern:
High level patterns to help specify the fundamental structure of a system.
• Design Pattern:
Medium scale patterns to organize subsystem functionality.
• Idioms:
Low level patterns to solve implementation specific problems.
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.
Arch.Pat. : From Mud To Structure
• The Layers Pattern
– helps to structure the applications that can be decomposed into groups of
subtasks in which each group of subtasks is at a particular level of abstraction.
• The Pipes and Filters Pattern
– Provides a structure for systems provides a structure for systems that process
a stream of data. Each processing step is encapsulated in a filter
component. Data is passed through pipes between adjacent filters.
Recombining filters allows you to build families of related systems.
• The Blackboard Pattern
– is useful for problems for which no deterministic solution strategies are
known. In Blackboard several specialised subsystems' assemble their
knowledge to build a possibly partial or approximate solution.
The Layers Pattern (Example)
The Layers Pattern (Example 2)
Layers Pattern: Benefits
• Reuse of layers :
If an individual layer embodies a well-defined abstraction and has a
well-detlned and documented interface, the layer can be reused in
multiple contexts.
• Support for standardization:
Clearly-defined and commonly-accepted levels of abstraction enable
the development of standardized tasks and interfaces. Different
implementations of the same interface can then be used
interchangeably.
• Dependencies are kept local: Standardized interfaces between layers
usually confine the effect of code changes to the layer that is changed.
Changes of the hardware, the operating system, the window system,
special data formats and so on often affect only one layer.
• Exchangeability:
Individual layer implementations can be replaced by semanticallyequivalent implementations without too great an effort.
Layers Patterns: Liabilities
• Cascades of changing behavior:
A severe problem can occur when the behavior of a layer changes.
• Lower efficiency:
A layered architecture is usually less efficient than, say, a monolithic
structure or a 'sea of objects'.
• Unnecessary work:
If some services performed by lower layers perform excessive or
duplicate work not actually required by the higherlayer, this has a
negative impact on performance.
• Difficulty of establishing the correct granularity of layers:
A layered architecture with too few layers does not fully exploit this
pattern’s potential for reusability, changeability and portability .
Distributed Systems: Broker Pattern
• 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,
such as forwarding requests, as well as for transmitting results
and exceptions.
Broker Pattern (Example)
Broker Pattern: Benefits
• Location Transparency. As the broker is responsible for locating a server
by using a unique identifier, clients do not need to know where servers are
located.
• Changeability and extensibility of components. If servers change but their
interfaces remain the same, it has no functional impact on clients.
• Porlability of a Broker system The Broker system hides operating system
and network system details from clients and servers by using indirection
layers such as APIs, proxies and bridges.
• Interoperability between different Broker systems. Different Broker
systems may interoperate if they understand a common protocol for the
exchange of messages.
• Reusability. When building new client applications. you can often base
the functionality of your application on existing services.
Broker Patterns: Liabilities
• Restricted efficiency. Applications using a Broker
implementation are usually slower than applications whose
component distribution is static and known.
• Lower fault tolerance. Compared with a non-distributed
software system. a Broker system may offer lower fault
tolerance.
• Testing and Debllgging. A client application developed from
tested services is more robust and easier itself to test.
However debugging and testing a Broker system is a tedious
job because of the many components involved.
Interactive Systems: MVC Pattern
• 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.
– A change-propagation mechanism
ensures consistency between the
user interface and the model.
MVC Pattern (Example)
MVC Pattern: Benefits
•
•
•
•
•
Allows Multiple views of the same Model.
Synchronized Views
“Pluggable” views and controllers
Exchangeability of “look and feel”
Framework Potential
MVC Pattern: 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
Difficulty of using MVC with modern user-interface tools
References
•
•
Software Architecture on wikipedia
http://en.wikipedia.org/wiki/Software_architecture
Pattern-Oriented Software Architecture: A System of Patterns
Frank Buschmann, Regine Meunier, Hans Rohnert,
Peter Sommerlad, Michael Stal
John Wiley and Sons, 1996
21