Pattern Views: Concept and Tooling for Interconnected Pattern Languages

03/20/2020
by   Manuela Weigold, et al.
University of Stuttgart
0

Patterns describe proven solutions for recurring problems. Typically, patterns in a particular domain are interrelated and organized in pattern languages. As real-world problems often require patterns of multiple domains, different pattern languages have to be considered to address these problems. However, cross-domain knowledge about how patterns of different languages relate to each other is either hidden in individual pattern descriptions or not documented at all. This makes it difficult to identify relevant patterns across pattern languages. Therefore, we introduce a concept and tooling that enables to capture patterns and their relations across pattern languages for a particular problem context.

READ FULL TEXT VIEW PDF

page 7

page 9

06/09/2020

Pattern Atlas

Pattern languages are well-established in the software architecture comm...
06/07/2019

On Pattern Setups and Pattern Multistructures

Modern order and lattice theory provides convenient mathematical tools f...
03/14/2022

Relational Diagrams: a pattern-preserving diagrammatic representation of non-disjunctive Relational Queries

Analyzing relational languages by their logical expressiveness is well u...
12/04/2020

Patterns, anticipation and participatory futures

Patterns embody repeating phenomena, and, as such, they are partly but n...
03/12/2019

Taxonomies in DUI Design Patterns: A Systematic Approach for Removing Overlaps Among Design Patterns and Creating a Clear Hierarchy

Recently a library of design patterns for designing distributed user int...
10/20/2003

Pattern Excitation-Based Processing: The Music of The Brain

An approach to information processing based on the excitation of pattern...
07/06/2018

Catalog of Formalized Application Integration Patterns

Enterprise application integration (EAI) solutions are the centrepiece o...

1 Introduction

Patterns describe proven solutions for recurring problems. After the first patterns were published in the domain of city and building architecture by Alexander et al. [1], the concept of patterns has been adopted in various other fields. Especially in software and information technology, publishing patterns has become a popular way to convey expert knowledge in different domains, e.g., object-oriented programming [20], enterprise application architecture [19], messaging [22], or security [37]. Since patterns can often be used in combination or offer alternative solutions, the relations between patterns are essential for identifying all relevant patterns and are therefore also documented. For example, the cloud computing pattern Public Cloud [18] describes how cloud providers can offer IT resources to a large customer group. It further refers to patterns that describe the different service models for offering resources, e.g., as Infrastructure as a Service (IaaS). When using the Public Cloud pattern, those related patterns should also be considered. In conjunction with the relations between them, patterns can be organized in pattern languages [1]. As a result, a pattern language describes how patterns work together to solve broader problems in a particular domain [12].

However, real-world problems often require patterns of different domains. Most likely, not all relevant patterns belong to the same pattern language. Therefore, some authors include references to other languages, e.g., Fehling et al. [6] state that the message queues of the Message-oriented Middleware pattern in the cloud computing patterns are introduced by Hophe & Woolf’s [22] pattern language as Message Channels. Unfortunately, not all relevant pattern languages are referred. For example, distributed cloud applications typically have to meet security requirements regarding the communication of the distributed components. To ensure secure communication, Schumacher et al.’s [37] Secure Channel pattern can be applied. However, this pattern language is not mentioned by Fehling et al. [18] at all. As references to other pattern languages are often missing, it is difficult to identify relevant patterns in other areas.

One reason for missing references is the way pattern languages are documented. Most pattern languages are published in books or scientific publications. Once they are published, they can hardly be changed and therefore the patterns languages remain static. This was not intended by Alexander et al. [1], who described them as living networks. Some authors created dedicated websites for their pattern languages (e.g., [11, 25, 23]), which eases the adaptation. Nevertheless, these websites represent only one particular language. For this reason, pattern repositories have been developed that aim to collaboratively collect patterns of various domains and provide tooling support to edit or extend patterns and relations.

Although several pattern repositories support the collections of patterns, patterns from different languages are sometimes treated only as a simple interconnected set and are not organized in pattern languages (e.g., [41, 31]). However, a pattern language is more than a collection of patterns. It reflects the higher-level domain for which the patterns are relevant [8], e.g., for realizing cloud applications. A few repositories organize patterns in pattern languages (e.g., [40, 30]), but do not explicitly reflect cross-domain relations between patterns in different languages. This knowledge is hidden in individual pattern descriptions. However, without explicitly cross-domain relations, and without the context in which these relations are relevant, it is difficult to identify relevant patterns for a given problem. This means that it must be possible (i) to assign patterns to a particular pattern language, (ii) to document cross-domain relations, and (iii) to specify the context in which a set of patterns and their relations are relevant.

To tackle these issues, we introduce a concept to explicitly document cross-domain knowledge relevant for a particular problem context. For this, patterns and their relations from different pattern languages can be selected and further relations can be defined as relevant in a specific context. The relations between patterns of different languages are cross-language relations that express cross-domain knowledge. Thus, it is possible to combine and extend pattern languages – a truly living network of patterns. Based on our previous experience with pattern repositories, we show how support for the concept can be integrated into the tool chain of an existing pattern repository. We also present a prototype that supports multiple pattern languages and their dynamical combination by using the new concept. The remainder of the paper is structured as follows: Section 2 describes fundamentals and a motivating scenario, Section 3 introduces our concept and tooling for it. We further present a use case in Section 4. Finally, Section 5 describes related work and Section 6 concludes the paper.

Figure 1: Patterns and relations of multiple pattern languages: Cloud computing patterns [18], enterprise integration patterns [22], and security patterns [37].

2 Background and Motivation

In this section, we first introduce patterns and pattern languages and then motivate that for real-world problems often patterns from multiple domains have to be considered.

2.1 Patterns and Pattern Languages

As already mentioned, patterns are used to gather knowledge about proven solutions for recurring problems in many different fields, e.g., humanities [5] or software engineering [12]. They describe the core idea of the solution on an general manner, which means in case of software engineering patterns that they are independent of a specific technology or programming language. The general solution concept of a pattern can therefore be applied to a variety use cases in different ways. Since humans are the targets, patterns are documented as textual descriptions according to a defined pattern format. Even if the pattern formats differ slightly from pattern language to pattern language [21], typical formats for patterns in software and information technology domains contain sections about the addressed problem, the context in which the problem might arise, forces which direct the problem, the proposed solution, the resulting context describing which forces have been resolved, and a section showing a sketch of the solution [13]. Often other patterns are only referenced in the textual description of one of these sections. Some authors have introduced explicit sections to describe the relations of the pattern and give them defined semantics [16], such as Variations [18, 25], See also [37] or Next [22].

Patterns and relations are the basic building blocks of pattern languages. In this work, we build on the premise that a pattern language is more than a collection of patterns, but a designed system [43]. This means that (i) relations of a pattern language are designed to guide the reader towards suitable patterns and (ii) each pattern solves a specific problem that is related to the overall context of the pattern language [28, 8], e.g., in the domain of cloud computing, enterprise integration, or security.

2.2 Motivating Scenario

Often patterns of several domains have to be considered for a real-world problem. For example, suppose a software developer wants to build a secure elastic cloud application. An elastic application responds to changing workload by adjusting the amount of resources allocated to the application [18]. This ensures that neither too many resources (which is costly) nor too few resources are allocated over a long period.

The cloud computing patterns in Figure 1 on the left provide several patterns relevant for an elastic cloud application: For example, an Elastic Infrastructure provides a dynamically adjustable infrastructure to a customer to deploy an application and an Elastic Queue can be used to monitor the number of message in a queue and to adjust the number of processing components handling the requests. In context of an elastic cloud application, the Processing Components are often implemented as Competing Consumers as any of the instances can receive and process an incoming request. Therefore, this enterprise integration pattern is explicitly referred to in the processing component pattern. Since messaging is often used for integrating cloud application components, the cloud computing patterns contain several messaging-related patterns, such as the Message-oriented Middleware pattern that also refer to other enterprise integration patterns. However, often references to related pattern languages are missing. For example, the enterprise integration patterns were published before the cloud computing patterns and thus never reference them. And although most elastic cloud applications must meet certain security requirements, such as secure communication between application components as provided by the Secure Channel pattern of the security patterns no security patterns are mentioned and thus no cross-language relations exist. It can easily be seen that cross-language relations are also important for pattern languages of other areas than software, e.g., for realizing a film scene, patterns from different domains (costumes, music and film settings) are needed [14].

But even if cross-language relations exist, they are often not properly documented. The pattern languages depicted in Figure 1 are published in books [18, 22, 37] or on dedicated websites [11, 23]. Besides scientific publications and dedicated websites, patterns are published in repositories that aim to collect patterns in collaboration [17]. However, even with the tooling support of current repositories it is challenging to find relevant patterns for a given problem: Several repositories do not organize patterns in pattern languages [41, 31] and treat patterns only as a simple interconnected set. The few repositories organizing patterns in pattern languages [17, 40] hide cross-language relations in individual pattern descriptions. None of the repositories known to us enables to document patterns and relations for a specific context (e.g., secure elastic cloud application). Consequently, finding suitable patterns across pattern languages for a certain problem is a cumbersome, manual process.

Figure 2: The concept of pattern views: Pattern views can comprise patterns of multiple (pattern view 1) or one pattern language (pattern view 2).

3 Pattern Views

In the following sections, we introduce pattern views as a concept to document cross-domain knowledge for a particular context that requires patterns and relations across pattern languages. We explain how pattern views can be integrated into the tool chain of a pattern repository by presenting our prototype.

3.1 The Concept of Pattern Views

Already Alexander et al.  [1] mentioned in the publication of the first pattern language that if a certain problem requires patterns of different pattern languages, patterns of different domains can be combined arbitrarily. Based on this idea we introduce pattern views as a concept (i) to explicitly define the context for which a set of patterns and relations is relevant, (ii) to specify new relations between patterns that are relevant in this specific context, and (iii) to preserve knowledge about the pattern languages from which the patterns originate.

Figure 2 illustrates our concept. A pattern view comprises patterns of either different pattern languages (pattern view 1) or one pattern language (pattern view 2). For example, patterns from different languages are relevant for a secure elastic cloud application, while only a subset of the cloud computing patterns are relevant for the deployment of a cloud application. The relations between the contained patterns in a pattern view are either those already defined in the original language or newly defined relations that are relevant in the defined context of the pattern view. Especially cross-language relations are often not embedded in the original languages. The relevance of a pattern view is determined by its context. The context guides the pattern users, e.g., software architects, to identify a pattern view for his or her particular problem. Thus, pattern views enable to document knowledge about combining patterns and pattern language for a particular problem explicitly and reusable for other users. In Section 4 a pattern view containing patterns relevant in the context of secure elastic cloud applications is described in detail. As a result, an individual pattern can be considered from different perspectives: It is primarily anchored in its original pattern language, but can also be part of different views that place the pattern in a specific context. As a pattern view can reuse and extend the existing structure of underlying pattern languages, new structures emerge. This supports the notion of Alexander’s living network of patterns that is constantly changing.

The term pattern view is inspired by two existing concepts in computer science: In database management systems, database views can be used to represent subsets of data contained in regular tables. They can join, aggregate, or simplify data from multiple tables and represent them as a single database view. For patterns, the same can be done by our pattern views: Patterns from multiple data sources (pattern languages) can be included in a pattern view. New relations for the pattern view can be defined, just like a database view can refer to another table. Another analogy to pattern views is the notion of architecture views in architecture descriptions [24]. An architecture view represents the architecture of a system from a specific viewpoint that is in accordance with a certain set of stakeholders’ concerns [24]. Depending on the concerns of the different stakeholders, a suitable architecture description can be created, e.g. a process view for process architects or a software distribution view for software developer. While Avgeriou & Zdun [2] use this definition to assign architectural patterns to their primary architectural view, e.g., the Client-Server pattern to the component-interaction view, we only adopt the idea of views and define pattern views as a representation of pattern languages from a particular viewpoint. The context of a pattern view represents the viewpoint from which the patterns and pattern languages are viewed to address the concerns of the pattern user.

In section Section 4 we present a pattern view for secure elastic cloud applications that is aimed towards cloud software architects and contains several patterns for the integration of the application components. Even if we motivate our work on the basis of information technology pattern languages, our concept is not limited to them but can be applied, e.g., to patterns for film costumes [6] or building architecture [1].

3.2 Tooling for Pattern Views

In previous works, PatternPedia111https://github.com/PatternPedia [17] has been introduced as a collaborative tool for documenting and managing patterns and pattern languages, as well as concrete solutions that are implementations of the patterns with a particular technology or in a particular programming language, in case of software engineering patterns. Pattern research is actively supported, as experts can analyze concrete solutions in collaboration and as a result identify best practices and document patterns [17].

Figure 3 illustrates the abstract architecture of PatternPedia with the newly developed components in dark grey. In the pattern repository patterns and relations between them are managed. The patterns as well as their relations are organized in pattern languages. The metadata defines the pattern formats for the different pattern languages as well as the semantics of the relations. Analogously, the solution repository stores concrete solutions and their relations, which are organized in solution languages. In addition, aggregation descriptors are stored that specify how different concrete solution artefacts can be combined [15]. The aggregation descriptors are used to annotate the relations between the concrete solutions in the solution languages. The solution repository for managing solution languages depends highly on the domain of the solution, e.g., for concrete solutions of costumes detailed descriptions of clothing pieces are relevant [4] whereas solution of software patterns can be code snippets [17]. The PatternPedia editor facilitates to add patterns as textual descriptions and browse the patterns and pattern languages as well as solution languages.

In this work, we enriched the pattern repository of PatternPedia by the concept of pattern views and a graphical editor222A demo can be found here: https://bit.ly/391T7Wz. The repository has been extended by the functionality to create pattern view definitions that specify the context of a particular pattern view and reference the existing relations and patterns across pattern languages that are part of the pattern view. Additionally, view-specific relations can be defined in the context of a particular pattern view. These view-specific relations add additional knowledge about how patterns in a certain context are interrelated.

As pattern and their relations are commonly represented as a directed graph with nodes representing patterns and edges representing relations [16, 12, 33, 44] (a representation we use in figures throughout this paper), we use a graph-based representation to visualize the graph structure of pattern languages and pattern views in the graphical editor. Within the graphical editor, relations of a pattern can be inspected in detail, and new relations can be added by drawing arrows between two patterns. Additionally, the visualization of the graph can be adapted by re-positioning nodes, zooming in and out, and triggering an automatic reordering of the graph layout based on the edges. Users can therefore directly edit or interact with the visualized pattern graph and observe how new relations or patterns lead to structural changes as the overall structure of the network of patterns can be grasped immediately. In the course of this work we not only conceptually extended the pattern repository but also refactored the implementation. The user interface of the pattern repository was reimplemented as an Angular frontend333https://github.com/PatternPedia/pattern-pedia-views-ui and we used Spring Boot for implementing a RESTful backend444https://github.com/PatternPedia/pattern-pedia-views-backend.

Figure 3: Abstract Architecture of PatternPedia.

4 Case Study

In our motivating scenario in Section 2.2, we stated that patterns from multiple domains are needed for realizing a secure elastic cloud application. In this section, we present a case study with the pattern view for the context of secure elastic cloud applications.

Figure 4: Architecture of a secure elastic cloud application.

Users expect certain applications to be always available. To fulfil these expectations, cloud providers offer infrastructure and services that can be used to guarantee the availability of an application even for a sudden increase of demand. Elastic cloud application deal with changing demand by adjusting the amount of resources that are used for the application [18]. In addition, data security plays a major role, especially when data is exchanged between communication partners.

Figure 4 depicts the architecture of a secure elastic cloud application. The application consists of a User Interface component that communicates with Processing Components via messaging. Both components are hosted on an Elastic Infrastructure. The number of messages in the channel is monitored to determine the workload of the processing component instances. Depending on the number of messages, the Elastic Queue adjusts the number of instances. As any processing component instance can answer a request, the component is implemented as Stateless Component and its instances act as Competing Consumers listening on a Point-to-Point channel provided by a Message-Oriented Middleware. After consuming and processing a message the processing component instance can send an answer via another point-to-point channel. To ensure data security, the communication between the component must be encrypted.

For such an application, there are a number of patterns that should be taken into account during implementation. In Figure 5, the pattern view for secure elastic cloud applications is shown. It includes patterns from the cloud computing, enterprise integration, and security pattern languages which are relevant in this specific context. Besides existing relations from the original pattern languages, three new cross-language relations (dashed arrows) are contained in the pattern view. In addition to the already named patterns also a Message Dispatcher can be used to delegate the message to one specific consumer, i.e. one processing component instance. Each Competing Consumer can be implemented as Polling Consumer, Event-Driven Consumer, or a combination of both [22]. A Message-oriented Middleware provides the functionality for communication via messaging and therefore also the message channels for competing consumers. To ensure that a message is consumed only once, the consumers must all listen to the same Point-to-Point Channel. As all transferred data of the application must be encrypted, the point-to-point channel must also implement the Secure Channel pattern. Once defined, this pattern view can be used by other cloud application architects to realize their secure elastic cloud applications. Since the existing knowledge is only enriched by the pattern views, further relevant patterns outside the view can be identified by the existing relations in the pattern languages.

Figure 5: Pattern view for secure elastic cloud applications,
refer to Figure 1 for a legend of the relation types.

5 Related Work

Several authors have examined relations and patterns across multiple pattern languages. Avgeriou & Zdun [2] reviewed architectural views and patterns from different languages. They assigned each architectural pattern to its primary architectural view and defined relations between the patterns. As each of their collection of patterns and relations for an architectural view is worth documenting, we adopted the idea of views as a concept that is not limited to the domain of IT architecture. Caiza et al. [10] standardize the relations of various privacy pattern languages to combine them into a new pattern language. Porter et al. [33] derived a method to combine pattern languages based on pattern sequences. In contrast, pattern views contain only those patterns of different languages and their relations that are relevant in a certain context. Thus, pattern views are more specific and less complex than potentially large combined pattern languages.

Buschmann et al. [9] introduce pattern stories as textural descriptions that walk a reader through the application of multiple patterns. In an exemplary pattern story, they demonstrate how patterns of multiple languages are used together. However, pattern stories are targeted at illustrating common pattern sequences. Pattern views are not limited to express sequential steps but can express arbitrary relationships.

Reinfurt et al. [35] present an algorithm for finding entry points in pattern languages. Their algorithm can be used to support several manual steps that are needed to document pattern views: For a formalized set of problems related to the context of the pattern view, their algorithm suggests suitable languages and a pattern that serves as a starting point.

Köppe et al. [26] elaborated requirements for online pattern repositories. He used the term pattern views in the sense that there should be different options (pattern views) for displaying a pattern, e.g., for smaller screens or optimized for printing. His notion of a pattern view, therefore, defines the visual representation of a pattern whereas we use the term pattern view for a concept to encompass patterns and relations that are relevant for a particular context. Apparently similar terms from other domains are process views and process viewing patterns [38]. Process views are used to represent a complex business process regarding certain aspects, e.g. by reducing the process to its essentials parts [38]. They are obtained by applying transformations on the process graph of the business process [39]. These transformations have been described by process viewing patterns [38]. In contrast to pattern views that are created by selecting suitable nodes (patterns) and redefine the relations (edges) between them, these transformations can be far more sophisticated, e.g., nodes of an process graph can be aggregated.

Pavlič et al [32] introduced the concept of pattern-containers to represent pattern collections. They formalized how patterns represent knowledge in an ontology. Relations are modeled by specifying that a pattern is related to another pattern. Unfortunately, in their ontology, the relation can not be described further and thus, the type of the relation can not be defined. They define pattern-containers as a way to create pattern collections: Pattern-containers can include patterns and other pattern-containers. A pattern can be included in multiple pattern-containers. But given their ontology, pattern-containers can not be used to represent pattern views: As it can not be defined what relations are relevant for a pattern-container, they represent a simple subset of patterns.

Graph-based representations for pattern languages are commonly used to reflect Alexander’s description of a network of patterns [9, 16, 44]. Another pattern repository, The Public Sphere Project mentions that a graph representation of all of their patterns and relations was once created [40], but only a sub-graph of it (8 patterns and their relations) can still be found on their website. Nevertheless, even the complete graph is still a static representation of their underlying living pattern network. Schauer & Keller [36] developed a tool for documenting software systems. Although they use patterns to enhance multiple graph-based views for a software system (e.g. as annotations in UML diagrams), they do not offer a general view on patterns. Welicki et al. [42] developed a visualization tool that can be used to search and create relations (including cross-language relations) between patterns in their software pattern catalog. They also implemented different views on a pattern that display e.g. a summary or software-specific views (e.g. source-code of a concrete implementation). The MUSE repository of Barzen [7] offers a graph-based representation of concrete costumes that occur in films and are understood as concrete solutions for costume patterns. However, these tools and repositories do not offer different perspectives on the relations of the patterns or pattern languages. Therefore, no other pattern repository or tool known to us offers graph-based representations of pattern languages and the ability to  [7] dynamically combine patterns from different languages to pattern views for a particular problem context.

6 Conclusion and Future Work

In this paper, we introduced the concept of pattern views to explicitly document cross-domain knowledge relevant for a particular problem context. Patterns from either different pattern languages or one pattern languages that are relevant for a specific problem can be combined to a so-called pattern view. In addition to the existing patterns and relations of the underlying pattern languages, view-specific relations can be defined if necessary for the given context. Therefore, cross-domain knowledge expressed by these relations is documented explicitly and within a meaningful context.

We extended our pattern repository that was presented in previous works [17, 15] by the concept of pattern views. Therefore, our repository allows to collect multiple pattern languages, and to define pattern views that can combine, reuse, and extend the structure of pattern languages that is given by the patterns and their relations. Our repository also offers a graph-based representation for the visualization of pattern views and pattern languages that visualizes the network of patterns. We plan to collect further pattern languages in the repository, such as Internet of Things patterns [34] or green IT patterns [29] and to extend our collection of pattern views. We will further evaluate if some pattern needs to be adapted to be used in the context of a pattern view. For future research we will especially consider patterns from new research areas such as music [3] or Quantum Computing [27]. Patterns for quantum computing are interesting as new technologies need to be integrated into our current software systems (for which we already have patterns at hand). Also, an open access hosting of the pattern repository would offers multiple advantages in future.

Acknowledgment

This work was partially funded by the BMWi projects PlanQK (01MK20005N) and IC4F (01MA17008G). The authors would like to thank Lisa Podszun for her help with the documentation of existing patterns.

References

  • [1] C. Alexander, S. Ishikawa, and M. Silverstein (1977-08) A Pattern Language: Towns, Buildings, Construction. Oxford University Press. Cited by: §1, §1, §3.1, §3.1.
  • [2] P. Avgeriou and U. Zdun (2005-07) Architectural Patterns Revisited – A Pattern Language. In In 10th European Conference on Pattern Languages of Programs (EuroPlop 2005), Cited by: §3.1, §5.
  • [3] J. Barzen, U. Breitenbücher, L. Eusterbrock, M. Falkenthal, F. Hentschel, and F. Leymann (2016-11) The vision for MUSE4Music. Applying the MUSE method in musicology. Computer Science - Research and Development, pp. 1–6. Cited by: §6.
  • [4] J. Barzen, M. Falkenthal, and F. Leymann (2018-Mai) Wenn kostüme sprechen könnten: muse - Ein musterbasierter Ansatz an die vestimentäre Kommunikation im Film. Beitrag in Buch Digital Humanities. Perspektiven der Praxis, pp. 223–241. Cited by: §3.2.
  • [5] J. Barzen and F. Leymann Patterns as Formulas: Patterns in the Digital Humanities. In Proceedings of the Ninth International Conferences on Pervasive Patterns and Applications (PATTERNS), Athen, pp. 17–21. Cited by: §2.1.
  • [6] J. Barzen and F. Leymann (2015-Juni) Costume Languages as Pattern Languages. Workshop-Beitrag In Proceedings of PURPLSOC (Pursuit of Pattern Languages for Societal Change). The Workshop 2014, P. Baumgartner and R. Sickinger (Eds.), Krems, pp. 88–117 (Englisch). External Links: ISBN 978-3-7375-5458-9 Cited by: §3.1.
  • [7] J. Barzen (2018) Wenn Kostüme sprechen - Musterforschung in den Digital Humanities am Beispiel vestimentärer Kommunikation im Film. Ph.D. Thesis, Universität zu Köln. Cited by: §5.
  • [8] J. O. Borchers (2008) A Pattern Approach to Interaction Design. In Cognition, Communication and Interaction: Transdisciplinary Perspectives on Interactive Technology, S. Gill (Ed.), Human-Computer Interaction Series, pp. 114–131. External Links: ISBN 978-1-84628-927-9 Cited by: §1, §2.1.
  • [9] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal (1996-10) Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. Wiley. Cited by: §5, §5.
  • [10] J. C. Caiza, Y. Martín, J. M. Del Alamo, and D. S. Guamán (2017) Organizing Design Patterns for Privacy: A Taxonomy of Types of Relationships. In Proceedings of the 22Nd European Conference on Pattern Languages of Programs, EuroPLoP ’17, pp. 32:1–32:11. External Links: ISBN 978-1-4503-4848-5 Cited by: §5.
  • [11] Cloud computing patterns. Note: https://cloudcomputingpatterns.org Cited by: §1, §2.2.
  • [12] J. O. Coplien (1996) Software Patterns. SIGS Books & Multimedia. Cited by: §1, §2.1, §3.2.
  • [13] J. O. Coplien (1996) Software patterns. SIGS, New York; London. Cited by: §2.1.
  • [14] M. Falkenthal, J. Barzen, U. Breitenbücher, C. Fehling, F. Leymann, A. Hadjakos, F. Hentschel, and H. Schulze (2015-06) Leveraging Pattern Application via Pattern Refinement. In Proceedings of the International Conference on Pursuit of Pattern Languages for Societal Change (PURPLSOC 2015), Cited by: §2.2.
  • [15] M. Falkenthal, J. Barzen, U. Breitenbüucher, and F. Leymann (2017) Solution languages: easing pattern composition in different domains. International Journal on Advances in Software, pp. 263–274. Cited by: §3.2, §6.
  • [16] M. Falkenthal, U. Breitenbücher, and F. Leymann (2018-10) The nature of pattern languages. In Proceedings of the International Conference on Pursuit of Pattern Languages for Societal Change (PURPLSOC), pp. 130–150. Cited by: §2.1, §3.2, §5.
  • [17] C. Fehling, J. Barzen, M. Falkenthal, and F. Leymann (2015-08) PatternPedia – Collaborative Pattern Identification and Authoring. In Proceedings of PURPLSOC (Pursuit of Pattern Languages for Societal Change). The Workshop 2014., pp. 252–284. Cited by: §2.2, §3.2, §3.2, §6.
  • [18] C. Fehling, F. Leymann, R. Retter, W. Schupeck, and P. Arbitter (2014-01) Cloud Computing Patterns: Fundamentals to Design, Build, and Manage Cloud Applications. Springer. Cited by: Figure 1, §1, §1, §2.1, §2.2, §2.2, §4.
  • [19] M. Fowler (2002-11) Patterns of Enterprise Application Architecture. Addison-Wesley. Cited by: §1.
  • [20] E. Gamma, R. Helm, R. Johnson, and J. Vlissides (1994-10) Design Patterns: Elements of Reusable Object-oriented Software. Addison-Wesley. Cited by: §1.
  • [21] S. Henninger and V. Corrêa (2007) Software pattern communities: current practices and challenges. In Proceedings of the 14th Conference on Pattern Languages of Programs - PLOP ’07, pp. 1. Cited by: §2.1.
  • [22] G. Hohpe and B. Woolf (2004) Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley. Cited by: Figure 1, §1, §1, §2.1, §2.2, §4.
  • [23] G. Hohpe Enterprise integration patterns. Note: https://www.enterpriseintegrationpatterns.com/ Cited by: §1, §2.2.
  • [24] Cited by: §3.1.
  • [25] Internet of things patterns. Note: http://internetofthingspatterns.com/ Cited by: §1, §2.1.
  • [26] C. Köppe, P. S. Inventado, P. Scupelli, and U. Van Heesch (2016) Towards extending online pattern repositories: supporting the design pattern lifecycle. In Proceedings of the 23rd Conference on Pattern Languages of Programs, PLoP ’16, USA. Cited by: §5.
  • [27] F. Leymann (2019) Towards a pattern language for quantum algorithms. In Quantum Technology and Optimization Problems, Lecture Notes in Computer Science (LNCS), Vol. 11413, Cham, pp. 218–230. External Links: Document Cited by: §6.
  • [28] G. Meszaros and J. Doble (1997) Pattern Languages of Program Design 3. pp. 529–574. Cited by: §2.1.
  • [29] A. Nowak, F. Leymann, D. Schleicher, D. Schumm, and S. Wagner (2011-10) Green Business Process Patterns. In Proceedings of the 18th Conference on Pattern Languages of Programs (PLoP 2011), Cited by: §6.
  • [30] Open pattern repository for online learning systems. Note: https://www.learningenvironmentslab.org/openpatternrepository Cited by: §1.
  • [31] Pattern catalog. Note: http://designpatterns.wikidot.com/pattern-catalog Cited by: §1, §2.2.
  • [32] L. Pavlič, M. Hericko, and V. Podgorelec (2008-07) Improving design pattern adoption with Ontology-Based Design Pattern Repository. pp. 649–654. Cited by: §5.
  • [33] R. Porter, J. O. Coplien, and T. Winn (2005-04) Sequences as a basis for pattern language composition. Science of Computer Programming 56 (1-2), pp. 231–249. External Links: ISSN 01676423 Cited by: §3.2, §5.
  • [34] L. Reinfurt, U. Breitenbücher, M. Falkenthal, F. Leymann, and A. Riegg (2017) Internet of things patterns for devices. In Ninth international Conferences on Pervasive Patterns and Applications (PATTERNS) 2017, pp. 117–126. Cited by: §6.
  • [35] L. Reinfurt, M. Falkenthal, and F. Leymann (2019) Where to begin: on pattern language entry points. SICS Software-Intensive Cyber-Physical Systems. Cited by: §5.
  • [36] R. Schauer and R. K. Keller (1998-06) Pattern visualization for software comprehension. In Proceedings. 6th International Workshop on Program Comprehension. IWPC’98 (Cat. No.98TB100242), Vol. , pp. 4–12. Cited by: §5.
  • [37] M. Schumacher, E. Fernandez-Buglioni, D. Hybertson, F. Buschmann, and P. Sommerlad (2013) Security patterns: integrating security and systems engineering. John Wiley & Sons. Cited by: Figure 1, §1, §1, §2.1, §2.2.
  • [38] D. Schumm, F. Leymann, and A. Streule (2010-10) Process Viewing Patterns. In Proceedings of the 14th International Conference on Enterprise Distributed Object Computing (EDOC 2010), pp. 89–98. Cited by: §5.
  • [39] D. Schumm, F. Leymann, and A. Streule (2010) Process views to support compliance management in business processes. In Proceedings of the 11th International Conference on Electronic Commerce and Web Technologies (EC‐Web 2010), 30 August – 3 September 2010, Bilbao, Spain, Lecture Notes in Business Information Processing (LNBIP), Vol. 61, pp. 131‐‐142. External Links: Document Cited by: §5.
  • [40] The public sphere project. Note: https://www.publicsphereproject.org/ Cited by: §1, §2.2, §5.
  • [41] UI patterns. Note: https://ui-patterns.com/ Cited by: §1, §2.2.
  • [42] L. Welicki, O. Sanjuán, J. Manuel, and J. Cueva Lovelle (2005-01) A Model for Meta-Specification and Cataloging of Software Patterns. Proceedings of the 12th Conference on Pattern Languages of Programs (PLoP 2012). Cited by: §5.
  • [43] T. Winn and P. Calder (2003) A pattern language for pattern language structure. In Proceedings of the 2002 conference on Pattern languages of programs, Vol. 13, pp. 45–58. Cited by: §2.1.
  • [44] U. Zdun (2007-07) Systematic Pattern Selection Using Pattern Language Grammars and Design Space Analysis. Software: Practice & Experience (9), pp. 983–1016. Cited by: §3.2, §5.