Modeling – Architectural Styles

Posted on May 11th, by Arnon Rotem-Gal-Oz in SAF. 1 Comment

I claimed in the past (on my “what’s software architecture” post) that Architecture is a type of design – if that is true, an interesting question is do we also have architectural patterns ?

I think the answer is yes – there are architectural patterns they are also called architectural styles – I actually like this term better as it is helps differentiate them from design patterns; for example I agree with  Harry Pierson’s observation that many of the patterns in Martin Fowler’s PoEAA are indeed technical patterns at an engineering or design level and not architectural patterns.

The difference between architecture styles and design patterns is similar to  the distinction between architecture and design – architectural styles effect the solution globally or at least it affects major parts of the solution and not solve local issues. Although it is interesting to note that some architecture styles have been well known well before the notion of design patterns for software was introduced.

SEI’s architecture glossary defines Architecture Style as

“A specialization of element and relation types, together with a set of constraints on how they can be used.”

That’s a good start but it might be a little hard to understand we can basically say that an architectural style  defines a family of solutions in terms of a pattern of structural organization using a vocabulary of  components and connector types (plus constraints on their use). It is also worth mentioning that different styles can be combined to create compound or derived styles.

I’ll try to illustrate what a style is using an example:

One of the basic architecture styles is “Layered architecture”:

The layered style is composed of layers (the components) which provides facilities and has a specific roles. The layers have communication paths / dependencies (the connectors).

In a layered style a layer has some limitations on how it can communicate with other layers (the constraints). Typically a layered is allowed to call only the layer below it and be called only by the layer above it (but there are variants e.g.  a layer can call to any layer below it; vertical layers that can call multiple layers; etc. – as long as the layers communication paths are limited by some rules)

You can see the application of layered style all over the place for example: logical software layers (e.g. presentation component, UI Controllers, business processes, business components, data entities, data access layer) , SOA layers (fundamental , Intermediate, Process), physical tiers (e.g. database server, application server, web server and clients)  etc.

There are many other architecture styles including for example pipe and filter, push based, peer-to-peer, blackboard, MVC, PAC, or the more recent Adaptive Object Models, REST and SOA (some will probably disagree that SOA is a style – but I’ll try to explain why I think it is on another opportunity). I’ll try to talk a little about some of them in the next posts.

Tweet about this on Twitter0Share on LinkedIn0Share on Facebook0Share on Google+0Buffer this pageShare on Reddit0Share on StumbleUpon0Email this to someone