1. What is Architecture?
 An overall blueprint/model describing the
structures and properties of a "system"
 designed mechanisms (causal chains & loops)
which lead to -
 emergent (intended) behavior (but always
some unintended behavior as well)
 "mapping" the boundaries (questions about the level
of "closure")

2. Software Architecture
• Captures the gross structure of a system
• How it is composed of interacting parts
• How the interactions take place
• Key properties of the parts
• Provides a way of analyzing systems at a high level
of abstraction !
• Illuminates top-level design decisions

3. Software Architecture Patterns
• Architectural pattern are software patterns that offer
well-established solutions to architectural problems in
software engineering. It gives description of the
elements and relation type together with a set of
constraints on how they may be used. An architectural
pattern expresses a fundamental structural
organization schema for a software system, which
consists of subsystems, their responsibilities and
interrelations. In comparison to design patterns,
architectural patterns are larger in scale.

4. Software Architecture Patterns
• The fundamental problem to be solved with a large
system is how to break it into chunks manageable
for human programmers to understand, implement,
and maintain.
• Large-scale patterns for this purpose are called
architectural patterns. Design patterns are similar,
but lower level and smaller scale than architectural
patterns.

5. Typical Architectural Patterns (styles)
File Transfer
Shared Database
- How can I integrate multiple applications so that
they work together and can exchange information?
integration styles for (enterprise) messaging
Remote Procedure
Messaging
•

6. Pipes and Filters
• The Pipes and Filters architectural pattern [style]
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. [POSA p53]

7. Example: Traditional Pipes & Filters
e.g. using sed and awk

8. Example: Apache Cacoon’s Pipes
& xslt Filters

9. Blackboard Architectural Pattern
"The Blackboard architectural pattern is useful for problems for which
no deterministic solution strategies are known. In Blackboard several
specialized subsystems assemble their knowledge to build a possibility
partial or approximate solution." (Buschmann, F., R. Meunier, H.
Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software
Architecture: A System Of Patterns. West Sussex, England: John Wiley
& Sons Ltd.)
The Blackboard pattern decouples interacting agents from each other.
Instead of communicating directly, agents interact through the mediation
of an intermediary agent. This intermediary provides both time and
location transparency to the interacting agents. Transparency of time is
achieved as agents who want to exchange data don't have to receive
the data when it is sent but can pick it up later. The locations of the
receiving agents are transparent in that the sending agent does not
need to address any other agent specifically by its name; the mediator
forwards the data accordingly.

10. The blackboard is an example of a passive coordination medium. While it
allows agents to share data, it does not specify how the agents are expected
to react to the data they receive. In other words, all the real coordination
knowledge remains hidden in the agents.
Blackboard Architectural Pattern

11. Tiered/layered Architecture Example:
Open Systems Interconnection (OSI) & Transmission Control
Protocol/Internet Protocol (TCP/IP)

12. Tiered Architecture (layering)
2 - tier architecture (traditional client-server)
A two-way interaction in a client/server environment, in which the user
interface is stored in the client and the data are stored in the server.
The application logic can be in either the client or the server.

13. 3 Tier Architecture

14. Model-View-Controller
The MVC paradigm is a way of breaking an application, or
even just a piece of an application's interface, into three
parts: the model, the view, and the controller. MVC was
originally developed to map the traditional input, processing,
output roles into the GUI realm:
Input → Processing → Output
Controller → Model → View

15. Model-View-Controller
The pattern isolates business logic from input and presentation,
permitting independent development, testing and maintenance
of each.

16. MVC View
It is the domain-specific representation of the data on which the
application operates. Domain logic adds meaning to raw data (for
example, calculating whether today is the user's birthday, or the
totals, taxes, and shipping charges for shopping cart items). When
a model changes its state, it notifies its associated views so they
can refresh.
Many applications use a persistent storage mechanism (such as a
database) to store data. MVC does not specifically mention the
data access layer because it is understood to be underneath or
encapsulated by the model. Models are not data access objects
although in very simple apps, with little domain logic, there is no
real distinction to be made. Also, the ActiveRecord is an accepted
design pattern which merges domain logic and data access code -
a model which knows how to persist itself.

17. MVC View & Controller
MVC View:
Renders the model into a form suitable for interaction, typically a
user interface element. Multiple views can exist for a single model
for different purposes.
MVC Controller:
Receives input and initiates a response by making calls on model
objects.
An MVC application may be a collection of model/view /controller
triplets, each responsible for a different UI element.

18. PHP MVC Frameworks
lots and lots…
codeigniter, cake, kohana, jelix, limonade, mojavi, zend,
zoop, symfony etc. etc.
see: http://www.phpwact.org/php/mvc_frameworks

19. MVC Fat Vs. Thin Controllers
watch: http://www.youtube.com/watch?v=91C7ax0UAAc
ruby on rails ‘fat’ model, ‘thin’ controller approach

20. Rails MVC : Model
ActiveRecord:
• Maintains the relationship between Object and Database
and handles validation, association, transactions, and
more.
• This subsystem is implemented in ActiveRecord library
which provides an interface and binding between the
tables in a relational database and the Ruby program
code that manipulates database records. Ruby method
names are automatically generated from the field names
of database tables, and so on.

21. Rails MVC : View
ActionView :
• A presentation of data in a particular format, triggered 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.
• This subsystem is implemented in ActionView library
which is an Embedded Ruby (ERb) based system for
defining presentation templates for data presentation.
Every Web connection to a Rails application results in
the displaying of a view.

22. Rails MVC : Controller
ActionController:
• The facility within the application that directs traffic, on the
one hand querying the models for specific data, and on the
other hand organizing that data (searching, sorting,
massaging it) into a form that fits the needs of a given
view.
• This subsystem is implemented in ActionController which
is a data broker sitting between ActiveRecord (the
database interface) and ActionView (the presentation
engine).

23. MVC Advantages
The main objective of the MVC design pattern is separation of
concerns. It provides an isolation of the application’s presentation layer
that displays the data in the user interface, from the way the data is
actually processed. In other words, it isolates the application’s data
from how the data is actually processed by the application’s business
logic layer. The biggest advantage of the MVC design pattern is that
you have a nice isolation of these components/layers and you can
change any one of them without the rest being affected. Here is the list
of the major advantages of this pattern.
• It provides a clean separation of concerns.
• It is easier to test code that implements this pattern.
• It promotes better code organization, extensibility, scalability and
code re-use.
• It facilitates de-coupling the application's layers.