Contents 3 Architectural patterns Introduction 39 1 Patterns 40 1.1 Why are patterns helpful? 40 1.2 Pattern schema or template 41 1.3 Design patterns and architectural patterns 41 2 Examples of architectural patterns 41 2.1 Layers pattern 42 2.2 Client-Server pattern 44 2.3 Master-Slave pattern 46 2.4 Pipe-Filter pattern 47 2.5 Broker pattern 49 2.6 Peer-to-Peer pattern 51 2.7 Event-Bus pattern 52 2.8 Model-View-Controller pattern 53 2.9 Blackboard pattern 55 2.10 Interpreter pattern 56 3 Applying patterns: KWIC example 56 3.1 Shared data 57 3.2 Layers pattern 57 3.3 Event-Bus 58 3.4 Pipe-filter 58 4 Architectural styles 59 4.1 Choosing a style or a pattern 59 Discussion questions 60 38 Learning unit 3 Architectural patterns INTRODUCTION Before major development starts, we need to choose an architecture that will provide us with the desired quality attributes. Therefore we need a way to discuss architectural options and their quality consequences in advance, before they can be applied to a design. Our decisions at this stage can only be based on experience with architectural choices in previous systems. Such architectural experience, reduced to its essence and no longer cluttered with the details of the systems that produced it, is recorded in architectural patterns. Many systems have a similar structure. Distributed systems, for in- stance, can have a client-server structure, with clients making requests and a server processing those requests and answering them. When we observe a similarity, we want to know what is common among the so- lutions and what variations are possible. We ask in what circumstances an approach may be used, and how it should be used and customised for a particular system. An architectural pattern provides an answer to such questions. This learning unit introduces architectural patterns and their relation with design patterns. We will discuss several examples of architectural patterns, but these examples do not include all architectural patterns: we will discuss ways to classify them. Using an example, we will show the effect of different patterns on the same problem. The example makes clear that you need to be able to choose the right pattern for a given situation. To make the right choice, you need experience with different systems. Knowledge about patterns will help you to expand upon what you learn through experience, be- cause by learning about patterns, you learn from the experience of oth- ers. LEARNING GOALS After having studied this learning unit, you will be expected to be able to: – describe the structure and function of the patterns which are cov- ered in this unit – describe the advantages and disadvantages of the patterns which are covered in this unit – explain the difference between a style and a pattern – give examples of applications of the patterns covered in this unit – name examples of patterns that fit a certain style. 39 Open Universiteit Software Architecture LEARNINGCORE 1 Patterns Definition 16 (Architectural pattern) An architectural pattern is a proven structural organisation schema for software systems. A pattern is a description of a set of predefined subsystems and their re- sponsibilities. In a system structured according to the Client-Server pat- tern, for instance, two subsystems are distinguished: the client (which can have many instances) and the server (which is unique). The re- sponsibility of the client may be to show a user-interface to the user; the responsibility of the server may be to process many questions and to guard data that are of interest to the client. A pattern also describes rules and guidelines for organising the rela- tionships among the subsystems. The relationship between the client and the server is that the client asks questions and the server answers them. Patterns are written by people with lots of experience. Knowledge which could have remained hidden in the heads of these experienced people is made explicit in the form of patterns. This enables others to learn from that experience. Patterns are not constructed by a single person: they reflect the experience of many developers. They capture existing, well-proven solutions in software development and help to promote good design practices. Architectural style Architectural patterns are also called Architectural styles, or standard ar- chitectures, but the word architectural style is more often used for a concept that is less fine-grained than a pattern; several patterns may therefore belong to the same architectural style. We will explain the subtle differences later in this learning unit. 1.1 WHY ARE PATTERNS HELPFUL? When a certain kind of problem is solved by many developers in a sim- ilar way, and it is generally accepted that this way solves that prob- lem well, it becomes a pattern. A pattern is therefore something that addresses a recurring design problem for which a general solution is known among experienced practitioners: a pattern documents existing design solutions that have proved their worth. By writing a pattern, it becomes easier to reuse the solution. Patterns provide a common vocabulary and understanding of design solutions. Pattern names become part of a widespread design language. They remove the need to use a lengthy description to explain a solution to a particular problem. Patterns are therefore a means for documenting software architectures. They help maintain the original vision when the architecture is extended and modified, or when the code is modified (but they cannot guarantee it). 40 Learning unit 3 Architectural patterns Patterns support the construction of software with defined properties. When we design a client-server application, for instance, the server should not be built in such a way that it initiates communication with its clients. Many patterns explicitly address non-functional requirements for soft- ware systems. For example, the MVC (Model-View-Controller) pattern supports changeability of user interfaces. Patterns may thus be seen as building blocks for a more complicated design. 1.2 PATTERN SCHEMA OR TEMPLATE Pattern template Patterns are described using a pattern template or pattern schema. All of the many different templates have at least the following components: – context: the situation giving rise to a problem – problem: the recurring problem in that context. A solution to the prob- lem should fulfil requirements, consider constraints and have desir- able properties. These conditions are called forces. Forces may con- flict with each other (performance may conflict with extensibility, for instance). Forces differ in the degree to which they are negotiable – solution: a proven solution for the problem. The solution is given as a structure with components and relationships and as a description of the run-time behaviour. The first description is a static model of the solution; the second is a dynamic one. 1.3 DESIGN PATTERNS AND ARCHITECTURAL PATTERNS Design pattern What is the difference between design patterns and architectural pat- terns? Design patterns offer a common solution for a common prob- lem in the form of classes working together. They are thus smaller in scale than architectural patterns, where the components are subsystems rather than classes. Design patterns do not influence the fundamental structure of a soft- ware system. They only affect a single subsystem. Design patterns may help to implement an architectural pattern. For example, the Observer pattern (a design pattern) is helpful when implementing a system ac- cording to the MVC architectural pattern. The concept of patterns was originally introduced by Christopher Alexan- der in building architecture, in ‘A pattern language’ [3] (1977) and ‘The timeless way of building’ [2] (1979). Design patterns first attracted at- Gang of Four tention in software design and development (the Gang of Four book [22]). Since then, patterns have been used in more disciplines: there are ana- lysis patterns, user interface patterns, programming idioms, functional design patterns and so on. 2 Examples of architectural patterns In this section, we describe several architectural patterns. For each of these, we describe the components and connections involved, give one or more usage examples and discuss advantages, disadvantages and other issues. 41 Open Universiteit Software Architecture 2.1 LAYERS PATTERN Layer n Layer n - 1 FIGURE 3.1 Layers of different abstraction levels Layers pattern The Layers pattern (see Figure 3.1) helps to structure applications that can be decomposed into groups of subtasks, each of which is at a partic- ular level of abstraction. Each layer provides services to the next higher layer. Services in a layer are implemented using services from the next lower layer. Service requests are frequently done by using synchronous procedure calls. In short, this pattern means that conceptually different issues are im- plemented separately, and that layers of a higher abstraction level use services of a lower abstraction level, and not the other way around. This pattern has the following benefits: – A lower layer can be used by different higher layers. The TCP layer from TCP/IP connections, for instance, can be reused without changes by various applications, such as telnet or FTP. – Layers make standardisation easier: clearly defined and commonly accepted levels of abstraction make it possible to develop standard- ised tasks and interfaces. – Dependencies are kept local. When a layer shows the agreed inter- face to the layer above, and expects the agreed interface of the layer below, changes can be made within the layer without affecting other layers. This means a developer can test particular layers indepen- dently of other layers, and can develop them independently as well: this supports development by teams. A result of the above is that layers may easily be replaced by a different implementation. Example: networking protocols Figure 3.2 depicts the ISO Open System Interconnect seven layers pro- ISO/OSI protocol tocol (the ISO/OSI protocol).