Skip to main content

About this free course

Download this course

Share this free course

Software development for enterprise systems
Software development for enterprise systems

Start this free course now. Just create an account and sign in. Enrol and complete the course for a free statement of participation or digital badge if available.

7.4.1 Architectural patterns

A software architecture is the broad structure of a software system. It describes its parts and how they are put together, and also captures an underlying rationale and associated concepts, such as professionalism (liability) and constraints (such as standards and economics). The term architecture is, again, reminiscent of its use in buildings.

Architectural patterns (also known as architectural styles) codify recurrent software architectures by describing the key elements of the architecture and how they fit together (Buschmann et al., 1996). They also describe the qualities of systems that are assembled following the pattern (Shaw and Garlan, 1996; Bass et al., 1998). For instance, the Pipe-and-Filter architectural pattern prescribes two types of components, the pipes and the filters, which are used to transfer and transform data, respectively Their connection must be such that filters can only be linked through pipes. The patter is suitable for systems whose main aim is to transform data from one format to another through incremental transformations. The resulting systems are simple to understand and maintain, and their components are highly reusable.

Patterns are not just descriptions of solutions; they also indicate how to identify problem and its context, which strategy should be followed, and the consequences of applying the pattern. There are many different templates to describe patterns which have been used by different authors; we will adopt the following, adapted from Fowler (2002).

  • Name: This is the name by which the pattern is referred to; it should be evocative of what the pattern is about in order to create a pattern language that encourages meaningful communication between developers.

  • Intent: This is a brief description of the purpose of the pattern.

  • How it works: This is a description of the solution; it should be implementation neutral, and may include some UML notation.

  • When to use it: This is a description of when the pattern should be used, possible relations to other patterns, and possible trade-offs.

  • Example: This may include examples of application of the pattern.

During the course you will have an opportunity to study several patterns, within various phases of software development.

Exercise 14

  1. What makes the use of patterns different from applying a new development method?

  2. What is the difference between a framework and a pattern?



  1. Patterns concentrate on actual designs and on existing practical experience of solving problems; they represent previous experience. A pattern is not accepted if there are no existing examples of its use.

  2. While a pattern is a general solution (a rule) to a specific problem, a framework is more concrete and part of the solution. A framework comes with code to be reused as it is, or to be extended for specific customisations. Frameworks are also usually for a specific application domain, while patterns can be used with many domains. Frameworks are usually larger, while patterns solve small problems and can be used within frameworks, but not the other way round. For instance, the Observer pattern deals with dependencies between a model and its presentation. The MVC user interface framework uses the Observer pattern as well as other patterns (from the ‘Gang of Four’ book). Patterns are used by following the suggested structure in the implementation; the framework classes are subclassed and application-specific methods implemented. Patterns are small architectural elements, while frameworks are partial or total solutions in an application domain.