Patterns and Pattern Languages - Architecture

Notes from the "Roy Fielding's Dissertation"

A design pattern is defined as an important and recurring system construct.

A pattern language is a system of patterns organized in a structure that guides the patterns’ application. Both concepts are based on the writings of Alexander et al. [3, 4] with regard to building architecture.

A pattern defines a process for solving a problem by following a path of design and implementation choices.

Alexander's design philosophy is to identify patterns of life that are common to the target culture and determine what architectural constraints are needed to differentiate a given space such that it enables the desired patterns to occur naturally. Such patterns exist at multiple levels of abstraction and at all scales.

An architectural style as a co-ordinated set of constraints is applied to design space in order to induce the architectural properties that are desired of the system. By applying a style an architect is differentiating the software design space in the hope that the result will better match the forces inherent in the application, thus leading to system behaviour that enhances the natural pattern rather than conflicting with it.

---------------------

Patterns and Pattern Languages as Heuristics for Architecture.

Heuristics are an important aspect of architecture, an important informative tool if implemented correctly. A pattern or a set of patterns can be used as a heuristic for software architecture.

REST Notes.

This blog entry are some personal notes from the original Roy Fielding's dissertation.  REST Notes. a) "Form Follows Function" comes from hundred of years of design. b) The hyperbole of The Architects Sketch may seem ridiculous, but consider how often we see     software projects begin with adoption of the latest fad in architectural design, and only later discover whether or     not the system requirements call for such an architecture. c) Dissertation focuses on the junction between software and networking. d) A set of architectural constraints become an architectural style. e) REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability     of component interactions, generality of interfaces, independent deployment of components, and intermediary     components to reduce interaction latency, enforce security, and encapsulate legacy systems. I describe the     software engineering principles guiding REST and the interaction constraints chosen to retain those principles,     contrasting them to the constraints of other architectural styles. Points about Software Architecture. a) Abstraction. ( A complex system will contain many levels of abstraction, each with it's own architecture,     this is a recursive feature until it goes to the most basic level where it cannot be decomposed any further.). b) A system has multiple operational phases. (Startup, initialization , normal processing, re-initialization and shutdown).     And each operational phase has its own architecture. c) Architectural design and source code structure design are two separate activities. d) A component is defined by it's interface and the services it provide rather than the implementation behind it's interface. e) Data f) Configurations g) Properties h) Architecture encompasses both functional and non functional. i) Choosing the right architectural style for a  network-based application requires an understanding of the problem domain  and thereby the communication needs of the application, an awareness of the variety of architectural styles and the particular concerns they address.

Architecture Study Notes - Heuristics

The following are notes from the book "The Art of Systems Architecting"	By Mark W.Maier and Eberhardt Rechtin
Heuristics Do not assume that the original statement of the problem is necessarily the best, or even the right one. In partitioning choose the elements so that they are independant as possible; that is, choose elements with low external complexity and high internal complexity. The eye is the finest architect. Believe it. Simplify. Simplify. Simplify. Build in and maintain options as long as possible in the design and implementation of complex systems. You will need them. For a heuristic to be selected, the following must be true. The heuristic must make sense in the original problem domain, and shoud show a direct effect between cause and effect; it should reflect the success or failure of a system. The heuristic should be useful in solving more than the original problem. The heuristic should be easily rationalized in less than 5 minutes.	Architecture process:- Orientation (More Business , less technical). Orientation is purpose analysis , problem structuring , solution structuring, harmonizing and selection-abstraction. Purpose analysis is a broad based study of why the capability or system of interest has value? Value Model - an explicit model of the most important stakeholder's preferences.
Also discover new heuristics from technical journals, books, project reports, management treatises and conversations.	Generating heuristics:- Humor in heuristic. Use words that transmit the :thrill of insight" to the eye of the holder. For maximum effect try descriptive and prescriptive messages. Do not create a heuristic where it only has meaning to its creator. Rather than creating conditional heuristic, rather create one, where it analyzes the conditional statement. Applying Heuristic:- If it works, then it is useful. Knowing when and how is as important as what and why. When applied early to the solution space it is best. Too much of a good thing make make it worse, strive for a balance. Practice. Practice. Practice.

Conclusion: They provide the successive transitions from qualitative, provisional needs to descriptive and prescriptive guidelines, and thence to rational approaches and methods.