El principio de legalidad como un concepto de dominio universal En razón de lo anterior puede inferirse la importancia que radica para que el

Currently, most software pattern resources describe patterns based on authors’ experiences and observations. Some of these resources have pointed explicitly to the relationship between each pattern and its (apparent) QAs, i.e., Gamma et al.[1995] andBuschmann et al.[1996], while others do not; such asSchmidt et al.[2001] andFowler et al.[2003].

However, there are a few sources that analysed the identification of the relationships be- tween SPs and limited QAs, by using a scientific methodology (based on measurements and metrics),Freitas[2009], such as the work done byKim et al.[2006] andZayaraz[2010]. Both these approaches have been described in Chapter 2, and both methods provide a good step towards building a concrete framework for SPs-QAs relationships.

Also, there are different evaluation studies for patterns that concentrate on a specific aspect, such as the development of a set of assessment criteria for a design pattern forevaluation and comparisonpurposes as reported byKhwaja et al.[2013]; and thecategorisationof empirical studies that focused on software pattern application done byRiaz et al.[2015]. In addition, there is a study that tackles theeffectivenessof AspectJ2and Java programming using design patterns to capture functional and non-functional elements,Teebiga et al.[2016]; and theformalisation and quantification guidelines approach for theStrategydesign pattern developed by Hummel et al.[2017]. However, there aren’t any other studies reported yet, that match the study scope, objectives, process, and findings of this latter work.

3.8

Conclusion

This investigation of the relationship between QAs and SPs has highlighted two main issues. First, the conflict variations within patterns practice and documentation in the current liter- ature, which may be caused by different factors such as authors’ (in) experience and immaturity of the patterns in the field of software engineering. Second, there isn’t a formalised approach or process to be followed, fordescribingthe relationship between patterns and QAs, or forcate- gorisingthem in a more sensible, and formal/verifiable way. Both these issues have led to the

3.8. CONCLUSION

existence ofconflicting relationshipsbetween patterns and QAs, whichdecreases the utilisation of patternsby users.

There is no existing study that tackles these issues, investigates this problem domain with a clear process, and includes reliable references and standard quality models such as this research endeavour does. As a result, this work produces important comments through its findings, and a partial solution through its database repository, which assists users with searching, creating, deleting, or even modifying any SPs-QAs descriptions or relationships.

In future work, the QAs and SPs description tables will need further updating, improvement, and review for the current information , in order to enhance knowledge about patterns and QAs. Furthermore, they should also include forces, scenarios, and quality metrics, as well as other information deemed essential for comprehensive knowledge about software patterns and their QA relationships.

So, this study serves as an initial phase for the possibility of the development of an evalua- tion framework driven largely by metrics rather than individuals’ observations alone.

More research is needed and the next chapter reports of efforts to discover some of the factors that either close or widen the gap between software developers and the SPs domain.

Chapter

4

Factors Influencing Utilisation of

Software Patterns: A Questionnaire

Analysis Result

A pattern is described as a solution to a class of problems in a general context. When a pattern is chosen and applied, the context of its application becomes very specific.

4.1

Executive summary

The variation in description of patterns within contemporary literature makes the explana- tion of SPs-QAs relationships complex and difficult to follow, as discussed earlier (Chapter 3). Doing nothing about this situation is likely to have the eventual result that developers will be de- terred from utilising patterns and/or that they ignore quality attributes. Either of these scenarios may hinder the process of development significantly and/or the attainment of required system quality.

This study attempts to reveal and propose solutions for some of the current problems that are facing the effective utilisation of SPs during the process of software development. Unfortu- nately, there isn’t enough empirical research or evidence that is currently documented regarding this problem domain.

This chapter reports practitioners’ perceptions (with relevant experience) regarding differ- ent aspects of SPs, such as: 1) SPs usage trend through a survey method, in order to disclose reasons that motivate and/or demotivate their utilisation; and 2) the process and nature of their current documentation.

Consequently, further research is recommended to develop a framework/method and tools to support SPs documentation and usage, based on the significant results obtained by this study.

4.2

Introduction

Various studies have attempted to detect, examine, assess, and describe the relationship be- tween styles/patterns and QAs. Every study takes a unique focus with a scope within a particular QA and field, such asZayaraz[2010],Jung et al.[2006], andZhu et al.[2004]. Nevertheless, hardly any such studies have pointed out the relationship between architecture (including pat- terns) and quality attributes withina broad schemethat could be used for the majority of QAs.

Thus, there is a rising need for documenting software architecture by researchers (and expert practitioners) in order to provide more guidance on the methods used to design architectures. Despite the recognition of this need, and the great efforts byClements[2003],Bachmann et al. [2005], andBass et al.[2013] or ISO-42010 framework, there is still research and work to be done to produce significantly better solutions for this problem context.

To avoid repetition and having laid down the background literature on this subject within Chapters (2 and 3), this chapter and its associated Appendix D tries to address the aforemen- tioned problems and to confirm some of Chapter 3 findings.

A survey was conducted to identify the factors that are likely to aid (as opposed to hinder) developers with the effective use of patterns during their work. Thus the following objectives were paramount: