Patterns and Quality Attributes Refinement

To create or describe a pattern we should understand the concept of patterns and follow rules or constraints to document them in the right way. To assess patterns against QAs, we should do the same to the QA concept. The rest of this section lays out the problems that exist within the concept and rules of creating and documenting software architecture patterns that have a direct impact on their utilisation and evaluation. Also, this section presents justifications for building a (SPs-QAs) relationship database, and some of the challenges that have been faced during its construction.

3.3.1.1 Problems Discovered within the Current PatternDefinitions and Termi- nologies

Numerous pattern definitions are suggested for varying contexts. It might therefore seem difficult to define patterns in commonly acceptable terms. However, it seems sufficient to say that a pattern is essentially the solution to a problem within a particular domain, which can be applied to help resolve similar problems in different contexts within the same domain. The definition of ’context’ has evolved over time. For the purpose of this study I deemDey[2001] definition as the most appropriate and probably the most widely accepted.

Dey defines ‘context’ as “any information that can be used to characterise the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between (for example) a user and an application, including the user and the application”. Also, Alshaikh et al. [2008] andAlshaikh [2011] PhD thesis provide a recent and deeper analytical study ofcontext, its use in general, and in the software domain in particular.

Gabriel found the definition of a pattern as described by the GoF is “a solution to a prob- lem in a context,” is unacceptable, Coplien[2014]. He believed that it failed to illustrate the significance of the concept, and may have even caused misinterpretation amongst software pro- fessionals. Also he believed that many of the existing pattern definitions were indistinct and did not accurately express the implications patterns have. He therefore proposed a new defini- tion, amending an early version byAlexander[1979]: “Each pattern is a three-part rule, which expresses a relation between a certain context, a certain system of forces, which occurs repeat- edly in that context, and a certain software configuration which allows these forces to resolve themselves”.

Others, such as Buschmann et al. [1996], Fowler [1997], and Riehle et al. [1996], and Coplien[2014], have their own definition of ‘pattern’.

Most of the definitions share common key points with a few variations. Some are more elaborate than others or include further important aspects such as forces. Defining the driver forces and constraints in a pattern as a solution is an important step during pattern resolution, Alexander[1979].

Having different terminologies and names in real life to explain the same thing, often due to differences in cultural factors or language, is acceptable. However, this is inappropriate in the context of SPs, as it leads to confusion. It is therefore considered as an absence of standard- isation, which can cause major challenges,Garlan[2000].

The terminologies shown in the Figure 3.4 are being used within the current literature, Graça [2017] and Fairbanks [2018]. For example, the Architectural-Styles term is used by Bass et al. [1998], Fielding [2000], and Capilla et al. [2016]. While, Architectural-Pattern is termed by Buschmann et al.[1996] andRichards [2015]. Also, Alexander [1964],Fowler [1997], Bass et al.[2013], and Comyn-Wattiau et al.[2016] refer to Conceptual-Model; and

3.3. INVESTIGATION ANALYSES

lastly,Conceptual-Patternis used byRiehle et al.[1996] andGrone[2006].

Thus, theterminology problempersists, while thecontext of developmentschanges as shown in Figure 3.4, suggesting different concepts. But are they?

The philosophy surrounding the conceptual or architectural ‘model, style, and pat- tern’ inthe aforementioned terms attempts to convey a single idea through various explanations, all of which share the concept, components, restraints, and relationships that focus on a high abstraction level. However, the conceptual models should be explained further through detailed descriptions, in order to be able to move from an architectural context to a design context and so forth.

All theterminologiesshown in Figure 3.4, do have the sameconcept of pattern, which is to provide a solution for a specificproblem context.

Although, minor differences exist, which are based on each author’s visions and usage of patterns within variousdevelopment contexts, (e.g. architecture level or design level) .

However, common terminologies surrounding patterns and concrete descriptions might lead to improving the utilisation and understanding of SPs, which should minimise the confusion in the mindst of their users. Hence, these variations are challenging factors for this study.

The same discussion also applies to the design phase as briefly discussed below.

Coding Pattern Programming Pattern Idioms Design pattern Architectural Style Architectural pattern Conceptual Model Conceptual pattern Concept of P atter n Implementation Phase Design Phase Architectur al phase Conceptual phase Prob lem Domain (e .g. Secur ity) Terminologies Development Context Problem Context

Alexander defines design as “a process of synthesis, a process of putting together things, a process of combination ”,Alexander[1979].

According to Buschmann et al. [1996], “design patterns depict frequently occurring ar- rangements of interacting components, thus helping to resolve design dilemmas in a given frame of reference”. What this essentially suggests is that a pattern cannot be translated into code, but rather the pattern should be moulded in a way that it provides a solution to the problem.

Currently, software developers can select required patterns in the form of code, for example State Pattern, coded in Java,Barth et al.[2007, pp. 187-189]. Also, there are numerous patterns on the Internet, which are coded in different programming languages and are ready for use. In my opinion, I think that restricts the generalization concept of pattern description.

Therefore, I agree with Buschmann et al. [1996], that patterns should be highly generic with textual explanations in addition to block and connector diagrams, in order to support higher reusability in multiple contexts and better understanding. However, the textual explanations and the block and connector diagrams should not be arbitrary. Also, they should be applied within a common standardised procedure, description language and / or a framework. Consequently, their usability factor will increase due to the clarity of their descriptions. Also, divergences in pattern interpretation does not take them out of their context or main objectives.

Various definitions (rules) of design patterns that convey a diversity of terminology and de- scription are apparent when comparing the definitions ofAlpert et al.[1998],Wolfgang[1994], Coplien et al.[1995],Gamma et al.[1995], andBuschmann et al.[1996].

To conclude, the concept of ‘pattern’ can be used for describing an architecture, design, and implementation. What’s different then? It’s the diversity of the context. Hence, reducing pat- tern documentation conflicts, needs more research and standardised procedures, to help increase their effective use. Possible research includes research on the practices used to apply patterns, empirical research on industrial software projects concerning patterns usage, and empirical re- search that compares the latest documented SPs descriptions and if they applied differently in the real world.

3.3.1.2 Problems Discovered within Current PatternCategorisations

One manifestation of SPs diversity is their categorisation. A categorisation outline is em- ployed to organise the patterns as a collection so as to make them accessible for searching and storing by users.

The classification approaches for the investigated resources are:

• The first and the second volumes of the POSA patterns are based on two primary cate- gories: pattern and problemcategories. The pattern category is subdivided into 3 types within both volumes, while the problem category is organised into 10 types in POSA-V1, and 4 types in POSA-V2.

3.3. INVESTIGATION ANALYSES

• POSA-V3 patterns are based on 3 primary categories within the domain of typical re- source management life cycles. These categories areresource acquisition, resource life cycle and resource release.

• POSA-V4 patterns are categorised on the basis of13 technical topics and distributed systems. Bear in mind, that POSA-V4 has been added into this section for the purpose of classifi- cation study only, in order to emphasise the existence of SP categorisation problem. • The GoF team, however, used a different approach, classifying patterns based on pur-

pose and scope. ‘Purpose’ is further sub-categorised intocreational, structural, and be-

havioural, while ‘scope’ is divided into categories ofclasses and objects.

• The SEI book byBass et al.[1998] contains architectural styles that are categorised on the basis of respectivesubjects and relations. Bass et al.[1998] describes thirteen different styles, of which the five primary styles are independent components, data flow, data-

centre, virtual machine, and call and return. The primary styles signify the relationships

amongst the sub-styles and their respective topics. Taking that into account, theBass et al. [2013] version does not mention their styles’ categories.

• The book on security patterns bySchumacher et al.[2006] comprises pattern categories bearing reference toenterprise and system levelswithin the security domain, and its related to engineering and operations activities at all levels.

Based on this study, the context oftechnical topicsin (POSA-V4) is the same as the con- text oftechnical problems, as well as theproblem category, which are recognised within volumes 1 and 2. For example, the‘From Mud To Structure’, is described as a problem category in POSA-V1, and as a technical topic in POSA-V4.

Also,another example of the categorisations confusion, is concerning theInterpreter pat- tern, where GoF considers this pattern as a design (behavioural) pattern, but the SEI group considers it an architectural (virtual machine) style. So, what is theInterpreterpattern, and does this affect the reusability of this pattern? Can we use the same pattern, explained by GoF in the context of a virtual machine as explained by SEI group, or do we need to adjust it to fit the new context?

By comparing the targeted resources mentioned above, it is clear that there is no com- mon approach for categorising patterns. However, the ‘problem’ as a category con- cept, is shared between many pattern books, although under a variety of names, for example, it is named ‘purpose’ in GoF book; ‘problem’ in POSA-V1 and V2, ‘tech- nical topics’ in POSA-V4, and as ‘main style or related subject’ in SEI work.

This lack of a common classification, particularly for technical topics, such as software patterns, can end up complicating things for users, researchers, and readers. Therefore, when users seek appropriate patterns for resolving certain real-life issues, they are confronted with

different guides and classifications for what are essentially the same patterns. Whilst, this can assist the users in employing the patterns in diverse contexts, it may also contribute towards making the reuse factor of patterns more complex, unmanageable, and less efficient.