What is it?

The high level design, comprising the breakdown into top-level components, the externally visible properties of those components, and the communication and other relationships between them
Involves multiple views: structural, behavioral, execution
For a more detailed definition, see http://www.bredemeyer.com/whatis.htm

"Software architects are a confused lot." [blogger Pranshu Jain]

Patterns vs. Frameworks

Pattern
- Provides a common solution to a common problem in a context
Analysis/Design pattern
- Provides a solution to a narrowly-scoped technical problem
- Provides a fragment of a solution, or a piece of the puzzle
Framework
- Defines the general approach to solving the problem
- Provides a skeletal solution, whose details may be Analysis/Design patterns

The selection of the upper-level layers may be affected by the choice of an architectural pattern or framework. Thus, it is important to define what these terms mean.

A pattern codifies specific knowledge collected from experience. Patterns provide examples of how good modeling solves real problems, whether you come up with the pattern yourself or you reuse someone else's.

Frameworks differ from Analysis and Design patterns in their scale and scope. Frameworks describe a skeletal solution to a particular problem that may lack many of the details, and that may be filled in by applying various Analysis and Design patterns.

A framework is a micro-architecture that provides an incomplete template for applications within a specific domain. Architectural frameworks provide the context in which the components run. They provide the infrastructure (plumbing, if you will) that allows the components to co-exist and perform in predictable ways. These frameworks may provide communication mechanisms, distribution mechanisms, error processing capabilities, transaction support, and so forth.

Frameworks may range in scope from persistence frameworks that describe the workings of a fairly complex but fragmentary part of an application to domain-specific frameworks that are intended to be customized (such as Peoplesoft, SanFransisco, Infinity, and SAP). For example, SAP is a framework for manufacturing and finance.

What is a Design Pattern?

A solution to a common design problem.
- Describes a common design problem
- Describes the solution to the problem
- Discusses the results and trade-offs of applying the pattern
Provides the capability to reuse successful designs.

Design patterns are being collected and cataloged in a number of publications and media. You can use design patterns to solve issues in your design without "reinventing the wheel". You can also use design patterns to validate and verify your current approaches.

Using design patterns can lead to more maintainable systems and increased productivity. They provide excellent examples of good design heuristics and design vocabulary. In order to use design patterns effectively, you should become familiar with some common design patterns and the issues that they mitigate.

A design pattern is modeled in the UML as a parameterized collaboration. Thus it has a structural aspect and a behavioral aspect. The structural part is the classes whose instances implement the pattern, and their relationships (the static view). The behavioral aspect describes how the instance collaborate -- usually by sending messages to one another -- to implement the pattern (the dynamic view). A parameterized collaboration is a template for a collaboration.The Template Parameters are used to adapt the collaboration for a specific usage.These parameters may be bound to different sets of abstractions, depending on how they are applied in the design.

What is an Architectural Pattern?

Expresses a fundamental structural organization schema for a software system
Provides a set of predefined subsystems
- Specifies their responsibilities
- includes rules and guidelines for organizing the relationships between them
Examples
- Client-Server, Model-view-controller (M-V-C)
- Layers/Tiers, Pipes and filters
- Blackboard

Architectural Analysis is where you consider architectural patterns, as this choice affects the high-level organization of your object model.

Model-View-Controller: The MVC pattern is where an application is divided into three partitions: The Model, which is the business rules and underlying data, the View, which is how information is displayed to the user, and the Controllers, which process the user input.

Layers: The layers pattern is where an application is decomposed into different levels of abstraction. The layers range from application-specific layers at the top to implementation/technology-specific layers on the bottom.

Pipes and Filters: In the Pipes and Filters pattern, data is processed in streams that flow through pipes from filter to filter. Each filter is a processing step.

Blackboard: The Blackboard pattern is where independent specialized applications collaborate to derive a solution, working on a common data structure.

Architectural patterns can work together. (That is, more than one architectural pattern can be present in any one software architecture.)

The architectural patterns listed above imply certain system characteristics, performance characteristics, and process and distribution architectures. Each solves certain problems but also poses unique challenges.

A Notation for Patterns

Name
Problem: What is the goal or objective?
Context: What are the preconditions? Where can the pattern be applied?
Forces: Potential benefits, constraints, trade-offs
Solution: How to achieve the desired goal
Other possible elements:
- Examples
- Resulting context
- Rationale
- Related patterns
- Known uses

Client-Server

Partitions work between service providers (servers) and service requesters (clients)
Client and server may run on different computers, geographically separated
Interactions always initiated by client making request for service
Servers listen for incoming requests
Contrast to peer-to-peer architecture
Examples: e-mail (SMTP), web browsing (HTTP), database access (SQL)
Client-server interactions can be described in UML using sequence diagrams

Model-View-Controller

Model: domain-specific representation of the application data, e.g DB
- When model changes state, it notifies the view
View: renders the model into a form suitable for interaction, e.g. GUI
Controller: receives input and initiates a response by making calls on model objects
Separates domain logic from user input and presentation
- Permits independent development, testing, and maintenance of each

MVC Diagram

Multiple views and multiple controllers may be supported.

Layered Architecture Application

Context: A large system that requires decomposition.

Problem: A system that must handle issues at different levels of abstraction; for example: hardware control issues, common services issues, and domain-specific issues. It would be extremely undesirable to write vertical components that handle issues at all levels. The same issue would have to be handled (possibly inconsistently) multiple times in different components.

Forces:

Parts of the system should be replaceable
Changes in components should not ripple
Similar responsibilities should be grouped together
Size of components - complex components may have to be decomposed

Solution: Layered Architecture

Structure into groups of components that form layers on top of each other
Make upper layers use services of the layers below only (never above)
For strict layering: do not use services other than those of the layer directly below
Generally skip layers unless intermediate layers would only add pass-through components

Layers are called tiers if they are implemented by physically separate libraries or hosts.

Layering represents an ordered grouping of functionality, with the application-specific functions located in the upper layers, functionality that spans application domains in the middle layers, and functionality specific to the deployment environment at the lower layers.

The number and composition of layers is dependent upon the complexity of both the problem domain and the solution space:

There is generally only a single application-specific layer.
In domains with existing systems, or that have large systems composed of inter-operating smaller systems, the Business-Specific layer is likely to partially exist and may be structured into several layers for clarity.
Solution spaces, which are well-supported by middleware products and in which complex system software plays a greater role, have well-developed lower layers, with perhaps several layers of middleware and system software.

4-Layer Example

Specific functionality	Application-specific	Makes the application distinct
	Business-specific	Re-usable systems specific to the type of business
	Middleware	Platform-independent services, distribution
General functionality	System Software	Infrastructure: OS, DB, HW interfaces

This slide shows a sample architecture with four layers:

The top layer, Application layer, contains the application-specific services.
The next layer, Business-Specific layer, contains business-specific components used in several applications.
The Middleware layer contains components such as GUI-builders, interfaces to database management systems, platform-independent operating system services, and OLE-components such as spreadsheets and diagram editors.
The bottom layer, System Software layer, contains components such as operating systems, databases, interfaces to specific hardware, and so on.

Some Additional Software Architectural Patterns

Peer-to-peer (see below)
Multi-tier (layered distributed client-server)
Service-oriented architecture
Naked objects
Broker
Presentation-Abstraction-Control
Microkernel
Reflection
Implicit invocation

Broker

Context:
Problem: Relieve appliction developers of concern for details of remove communications
Forces:
- Embedding communication code in application means simple changes in communications infrastructure (e.g., encodings, security, medium) can force significant changes to application code
- Distribution often is an add-on, after development application is complete
- Communication details can be quite tedious, an error-prone
- For flexibility, the locations of specific components should not be coded into the system
Solution:
- Broker provides location of server to client
- Or broker intermediates client requests

See http://msdn.microsoft.com/en-us/library/ms978706.aspx for complete MSDN description, including interaction diagrams.

Peer-to-Peer

Participants provide services to other participants without central coordination
- No server-client distinction
Peers are both suppliers and consumers
Examples: file sharing (Napster)

Software Frameworks

May implement architectural patterns
Re-usable mini-architecture
Provides the skeleton of an application
Main objective : design reuse
Also usually includes concrete code, including some foundation classes
Often the extension mechanism is call-back

References

http://www.opengroup.org/architecture/togaf8-doc/arch/chap28.html: Open Group page on "Architectural Patterns", with links to lots of other good pages
http://www.bredemeyer.com/howto.htm: Bredemeyer's "Software Architecting" page, with links to lots of other pages with good detailed articles on various aspects of software architecture, including templates
http://en.wikipedia.org/wiki/Architectural_pattern_%28computer_science%29: Wikipedia article "Architectural patterns"
http://www.bredemeyer.com/pdf_files/ArchitectureDefinition.PDF: Malan & Bredemeyer, "Software Architecture: Central Concerns, Key Decisions" (one of the pages that can be found via links from the above)
http://www.medbiq.org/std_specs/techguidelines/softwarearchitecture.pdf: Example of a software architecture specification document (incomplete)
http://msdn.microsoft.com/en-us/library/ms998572.aspx: Microsoft patterns & practices

Software Architecture