Design patterns
A design pattern is a reusable solution to a commonly occurring problem in systems and software design.
The concept of the design pattern was introduced in the field of architecture and town planning by Alexander et al. (1977). The technique was adopted for solving software design problems by Gamma et al. (1995), and has since become widespread. One of the most well-known design patterns is the Model-View-Controller (MVC) pattern which is used by many Web development frameworks. When following the MVC pattern, developers create separate pieces of code to communicate with a database (model), communicate with the user (view) and perform application-specific data processing (controller). Beyond adoption of the MVC conventions, there is nothing which obliges the developer to separate functions out in this way. However, in doing so the code is made more comprehensible by following a predictable structure. Another developer familiar with the pattern can very quickly grasp the purpose of any particular piece of code.
With the proliferation of IoT implmentations, several authors have begun either to catalogue IoT design patterns found in the literature, or to actively develop patterns to accelerate development. A recent literature review identified 136 patterns in 33 published papers between 2014 and 2018 (Washizaki et al., 2019). The authors classified the patterns according to their level of abstraction, their domain-specificity and their quality characteristic. At the highest level of abstraction, the patterns described architectural models, while at the lowest level the patterns were aimed at solving recurrent detailed design problems. Some patterns were found to be so generic that they could be applied to many types of system other than IoT. This led the authors to conclude that in many cases, IoT design problems do not require specific approaches that are distinct from other computing domains.
A design pattern is generally described in structured text with the following elements (Reinfurt et al., 2017a):
| Element | Function |
|---|---|
| Name | Identifies the pattern |
| Aliases | Other names by which the pattern might be known |
| Icon | A graphical representation of the pattern that can be used in diagrams |
| Problem | The core problem that is resolved by the pattern. This is expressed without reference to a concrete domain or technology since the general problem might exist in many different use cases. |
| Context | Describes the circumstances in which the problem typically occurs, and which might impose constraints on the solution. |
| Forces | The considerations that must be taken into account when choosing a solution to a problem. These can often be contradictory. |
| Solution | The core steps to solve the problem, often including a sketch depicting the architecture of the solution. |
| Result | Elaborates the solution in greater detail and describes the situation we find ourselves in after applying the pattern. |
| Variants | Variations of the pattern which do not differ enough to need their own separate pattern description. |
| Related Patterns | Connections between patterns, such as patterns that are often applied together or patterns that exclude each other |
| Example | A concrete example that illustrates the application of the pattern and could also contain links to concrete solution artifacts. |
There is now a rapidly growing body of literature on design patterns for IoT covering several important aspects. Figure 1 summarises those patterns identified by Reinfurt et al. (2016, 2017a-d). Other patterns have beed identified for testing (Pontes et al., 2018) and security (Lee & Law, 2017) among others.
Figure 1: IoT design patterns. * indicates those discussed in Reinfurt (2017a)