The Problem of pattern interaction is an implication of pattern organisation and complexity of systems. This problem cannot be neglected during pattern selec- tion. The problem derives from the fact that combination of patterns affects system and have an impact on non-functional properties. A way in which pat- terns interact has to be carefully considered. It may strongly increase quality of a system, but it also may lead to a disaster. This section presents patterns that are applied together in real systems. The section is organized as follows:
1. Definition of Pattern Language – the subsection provides basic definition of pattern language, including criteria required to be fulfilled by a pattern language
2. Pattern Language in real systems – presents shortly results of studies about number of architectural patterns in systems
3. Popularity of architectural patterns in real systems – presents occurrences of particular patterns in real systems.
4. Representatives of categories in real systems – this section presents ap- plication of filter removing patterns that do not exist in pairs with other architectural patterns. The guidelines elaborated in this thesis shall be use- ful. This also means that the guidelines should be as much applicable as possible. What in turn means that the migrated pattern should be popu- lar - often used. Not often used patterns reduce usability of the guidelines because they cannot be applied frequently.
3.3.1
Definition of Pattern Language
Robert S. Hanmer and Kristin F. Kocan present [37] broad studies on mutual interaction of patterns. They provide following definition of pattern language:
Pattern languages are collections of patterns that can be used to build something larger than any individual pattern can be used to build. They present two criteria which define complete pattern language:
1. “Morphologically complete (i.e., complete enough that an entire solution can be seen from only the patterns present in the language)”
2. “Functionally complete (i.e., the language contains patterns that resolve all the new forces introduced by the use of the languages patterns). ”
According to Robert S. Hanmer and Kristin F. Kocan [8]definition of pattern language should contain following parts:
1. Abstract - provides high-level understanding of the pattern language. This part is usually a few sentences long.
2. Map - The map is a non-cyclic graph presenting patterns as nodes and relations between them as arcs. The arcs are directional. Arrowhead point the pattern that is influenced by the pattern on the opposite side of the arc. Each pattern presented on the map should contribute to the patterns that are in relation with this pattern.
3. Description - the description presents order of application of all the patterns creating the pattern language.
4. Patterns
(a) Name - the name of the pattern
(b) Problem - the problem that needs to be solved (c) Context - in fact, this is a cause of the problem
(d) Forces - presents factors that should be taken into consideration while applying the pattern.
(e) Solution - the pattern is a solution
(f) Result Context - this context presents results of application of the solution. What is gained or introduced.
3.3.2
Pattern language in real systems
An additional study in the domain of pattern languages was conducted by Har- rison B. Neil and Paris Avgeriou [38].During the study, documentation of real systems was analysed [16]. One of the outcomes of the studies was amount of identified patterns in the documentation. Result of analysis is presented below in table 3.4. Number of patterns found Number of system 1 10 2 22 3 9 4 4 5 0 6 1 7 0 8 1
Table 3.4: Identified amount of patterns. Adopted from [38]
Analysis of documentations stated that in ten systems only one architectural pattern was found. This number may be over the top, because it is possible that the reviewers of the documentations did not recognise all the patterns or just did not know the applied patterns. Moreover, if reviewers were not sure whether a pattern is an architectural pattern, the pattern was rejected as well. Nevertheless, 78% of systems were built using more than one architectural pattern.
3.3.3
Popularity of architectural patterns in real systems
The next outcome of the investigation is popularity of particular patterns ex- pressed as a number of occurrences of an architectural pattern in documentations. The summary of pattern “popularity” presents table 3.5
Pattern name Occurrences
Layers 18
Shared Repository 13
Pipes and Filters 10
Client–Server 10
Broker 9
Model– View– Controller 7
Presentation–Abstraction–Control 7 Explicit Invocation 4 Plug–in 4 Blackboard 4 Microkernel 3 Peer to Peer 3 C2 3 Publish–Subscriber 3 State Transition 3 Interpreter 2
Half Sync, Half Async 2
Active Repository 2
Interceptor 2
Remote Procedure Call 1
Implicit Invocation 1
Table 3.5: Popularity of particular patterns. Adopted from [38]
There is a strong correlation between table 3.5 and table 3.1, namely, most popular patterns from table 3.5, like Layer or Pipe And Filters exist in all source documents. Less popular patterns likePlug–in orState Transmission did not pass the first selection or do not exist there at all. Paris Avgeriou and Uwe Zdun [8] ] present one more very interesting outcome, a table 3.5presenting which exactly patterns interact with others.
Pattern name Occurrences
Layers – Broker 6
Layers – Shared Repository 3
Pipes Filters – Blackboard 3
Client Server – Presentation Abstrac- tion Control
3 Layers – Presentation Abstraction
Control
3
Pattern name Occurrences
Layers – Model View Controller 3
Broker – Client-Server 2
Shared Repository – Presentation Ab- straction Control
2
Layers – Microkernel 2
Shared Repository – Model View Con- troller
2 Client Server – Peer to Peer 2 Shared Repository – Peer to Peer 2
Shared Repository – C2 2
Peer to Peer – C2 2
Layers – Interpreter 2
Layers – Client Server 2
Pipes and Filters – Client Server 2 Pipes and Filters – Shared Repository 2
Client Server – Blackboard 2
Broker – Shared Repository 2
Broker – Half Sync/Half Async 2 Shared Repository – Half Sync/Half
Async
2 Client Server – Half Sync/Half Async 2
Table 3.6: Popularity of pairs of architectural patterns. Adopted from [38]
However, there are many pairs of patterns, not all are included. Reviewers ex- cluded sixty seven pairs that appeared only once.
3.3.4
Representatives of categories in real systems
Filter 6: Removal of rarely interacting patterns
Table presenting categories 3.3 with their representatives provides ten rep- resentative patterns as follows: Layers, Pipes and Filters, Shared Repository, Microkernel, Reflection, Model View Controller, Half Sync/Half Async, Client Server, Remote Procedure Call and Message Queueing. Additionally. Table 3.6, which is presenting popularity of particular patterns presents thirteen different patterns combined into pairs. The patters are as follows: Layers, Broker, Shared Repository, Pipes and Filters, Blackboard, Client Server, Presentation Abstrac- tion Controller, Model View Controller, Microkernel, Peer to Peer, C2, Inter- preter, Half Sync/Half Async. In order to minimize the list of potential patterns
to patterns that can cooperate with other architectural patterns, the lists should be intersected. The outcome of intersection removes a few patterns from list of representatives and provides the final list of patterns that are considered as po- tential candidates for migration. The list will be further reconsidered in terms of feasibility of migration toward SOA. The list of final patterns presents following entities:
1. Layers
2. Pipes and Filters 3. Shared Repository 4. Microkernel
5. Model–View–Controller 6. Half–Sync / Half–Async 7. Client–Server
In the result of intersection, three patterns were rejected: 1. Reflection
2. Remote Procedure Call 3. Message Queueing