Elementos de la Percepción

ture. However, none of them narrowed down to focus on these study aspects to encourage development of a systematic solution to document SPs better. The latter two surveys were too narrowed and specific to the GoF design patterns, and an investigation of the existing patterns studies, respectively.

Therefore this survey is important and can be seen as a proper combination of the two approaches, because it’s not too specific or too wide. Also, it is concentrated on SPs in general and from different aspects, such as, pattern documentation, factors deterring or supporting the use of patterns, and their relationships with QAs.

Also, good research has been conducted on “software design-pattern specification languages”,Khwaja et al.[2016]. Their focus was on object-oriented design patterns. Their research discussed languages based on, mathematical formalism, other modelling languages, and other languages. They did categorise them into description, analysis, and detection patterns languages.Despite the variation between the ob- jectives and scope of this research and their survey, one common conclusion was “the need for a unified framework for the evaluation of design patterns across different domains”.

To sum up this section, the current research discussed, including this survey, have a common goal to improve the process of software design and architecture (including its styles/patterns).Thus, I recommend inclusion of the findings of this current research into the process of developing concrete solutions for current software architecture and design challenges.

4.6

Limitations

It is worthy to note that this research has its own limitations, which calls for more research within related fields to fill the gaps identified in the research. The first limitation of this study is the optional questions, which allow the participants to skip some of the questions without providing answers. This results in low cell responses in the three and four dimensional analyses (explained earlier in Section 4.3.5, which leads to some invalid results, and minimises the chances of finding new significant relationships between different factors that could improve pattern utilisation. Another limitation is that most questions included in the questionnaire were close-ended. This may limit the opinions gathered from the respon- dents. Also, the limited sample size caused some invalid analysis results, which consequently limits the findings of this work.

Finally, this chapter only focused on SPs without considering the possibility of a better alternative to SPs for software designing and development. Therefore, I recommend more studies, as opposed to relying solely on the findings of this research, in order to come-up with solutions for some of the issues pointed out here.

4.7

Conclusion

The utilisation of well-documented SPs has the potential to improve the whole process of software evaluation and development, especially in architectural and design levels. However, in order for this potential to be realized, there is a need to identify the factors that could be hindering the use of SPs and come up with solutions. Research is one of the best tools to identify such factors and facilitate the proposition of possible solutions.

Through an inductive approach, this research has made an effort to establish the current trends in the utilisation SPs within the software development process. The research was able to capture a wide

audience across various fields of software development and collect their opinions about the factors that encourage or discourage the utilisation of software style/patterns. It was established that one of the main factors influencing the utilisation of SPs is documentation. This is also likely to affect how patterns will be utilised in the future. This is the reason why part of the thesis was dedicated towards analysing current and reliable patterns’ documentation, which aimed to help in establishing a systematic framework to provide clear guidelines for creating and documenting SPs.

Based on the findings of this study, the importance of QAs consideration within SPs cannot be ignored, as shown by the first statement in Table 4.14. Thus, software developers who consider QAs before using patterns are likely to be able to build better systems. It can therefore be concluded that the effectiveness with which software patterns can be applied depends largely on their QAs.

From the study, it was also clear that the continued utilisation of patterns in the future depends largely on the approach of their documentation. Findings also show that the respondents agreed to the suggested solutions, which were provided partially through statements in Q17 to Q20 of the survey. I therefore recommend that the suggestions be embraced and more research be conducted on each of them to determine the best way in which they can be implemented, in order to develop a SPs platform.

Table 4.14: Summary of the mainsignificantanalysis results with associated tables (for better traceability)

Findings Analysis

Table

Statistics (p-value)

Developers significantly agreed with the statement “Identifying the relationship between software patterns and quality attributes is very important to software developers and the software engineering field”

4.10 t = 9.50

(.0000)

Developers significantly agreed with the statement “Identifying standard qual- ity attribute definitions within current pattern references is a critical for com- paring the same patterns against the quality attribute they possess”

4.10 t = 4.34

(.0000)

Developers significantly agreed with the statement “Studying relationships be- tween patterns and quality attributes based on the current reliable software pat- tern references, and creating a database to store these relationships on the basis of standardised quality attribute definitions, is valuable knowledge”

4.10 t = 6.34

(.0000)

Developers significantly agreed with the statement “Developing an evaluation model to assess patterns against quality attributes is worthwhile, provided it’s not difficult to use”

4.10 t = 5.78

(.0000)

The developers who have expertise in architecture more frequently used soft- ware styles/patterns during their work, compared to who don’t have the exper- tise in architecture

4.11 t = 3.64

(.0005)

Designers more frequently used software styles/patterns during their work com- pared to the developers who have other expertise.

4.11 t = 2.28

(.0070) Programmers (Coders) more frequently used software styles/patterns during

their work compared to the developers who have other expertise.

4.11 t = 1.52

4.7. CONCLUSION

Developers who “care about or consider quality of attributes during their se- lection of patterns” used software styles/patterns more frequently than who did not care.

4.12 t = 2.22

(.0085)

Developers who “used software styles/patterns in the past and will keep using them in the future”, use patterns more frequently.

4.12 t = 5.26

(.0000)

In conclusion, SA and design can be greatly improved through the application of SPs. However, this process can also be hindered if software developers do not have the right experience and guidelines to apply SPs correctly. This research has laid out some important observations regarding the current trends in SPs. Further research is required as recommended within the findings section in order to ascertain how each of the issues discovered can be handled. In the end, through this study and other related research, a systematic framework can be achieved to guide the seamless application of software patterns in various fields. Two of the most urgent areas that need further research as recommended in this study include

Documentation and QAs of SPs. The anticipated result of successful application of SPs in software development is increased as developers improve the quality of their software, as well as saving time in the development process. Table 4.14 summarises the significant findings of this chapter.

Chapter

5

Utilisation of Software Architecture

Artefacts and its Evaluation

The architecture of complex software or systems is a collection of hard decisions that are very expensive to change. Successful product development and evolution depend on making the right architectural choices. Can you afford not to identify and not to evaluate these choices?

—Alexander Ran, Principal Scientist of Software Architecture, Noki

5.1

Executive summary

The quality of a software product depends largely on the architecture and design processes. Quality characteristics are measured and evaluated using various evaluation methods. Also, the utilisation of various software architecture artefacts hasNOT been fully embraced by software developers, as noted from the previous questionnaire analysis in Chapter 4. This raised curiosity about the factors that could hinder or encourage the utilisation of these artefacts. Therefore, this research reported in this chapter is a continuing effort to the study reported in previous chapters.

Thus,one of the main aimsin this chapter is to reveal the various factors that affect positively or negatively SA model/artefact utilisation among professionals from various fields;the second aimis to uncover any relationships between Software Architecture Evaluation (SAE) and various factors affecting SA; in order to improve the supportive factors and decrease the impact of the hindering factors. The research methods used during this part of the research werea survey and field study.

5.2

Introduction

Having realised the importance of SPs in Chapter 4, which form an essential part of SA artefacts, it seems apparent that there is a need for more research regarding SA and SAE, in order to improved their methodologies. Despite the issues concerning SP-QA relationships, the analysis in Chapter 4 re- vealed that there is a high potential for quality improvement during the proper utilisation of SPs, with a consequential improving of SA descriptions and assessment.

There are various studies that have tried to analyse the relationship between SA and QAs. Such studies include the research byBass et al.[1998],Moreno et al.[2008],Zayaraz[2010],AV Sriharsha

[2015],Khwaja et al.[2016],Lugou et al.[2016],Ribeiro et al.[2017], andBrouwers et al.[2017]. Each of these studies focused on a specific architecture view, such as SPs, a specific QA, or modelling and languages.

However, there is no study yet published, which combines the investigation of SA, SAE, and SA modelling techniques, through two different approaches, as is case in this study. The two pillars of investigation (brown boxes) reported in this chapter are illustrated in Figure 5.1.

Chapter-5 Main Sections

Intro. Survey

Analysis Field Study Conclusion

Figure 5.1: The two pillars to investigate SA, SAE, and SPs relationships.

Therefore, the objectives of this chapter are:

• To explore the current trend of SA developmenta_{among developers from different fields} of software development. By studying these trends, the courses of action (e.g. more