By Kuznetsov Mikhail (makuznetsov_4@edu.hse.ru)
Beginner or experienced developer, designer – everyone regularly faces the need to create software in accordance with the requirements of the customer or the development team. This, in turn, is always accompanied by an integral part of the entire development process – design. A special role in this stage is played by patterns – a structured textual and graphical description of a proven solution to a recurring design problem. However, these are not heuristics or complete step-by-step guides on problem-solving. Instead, they represent the best practices [1]. They prevent unnecessary refactoring and lead to the creation of well-structured, easy-to-maintain and reusable software systems. Their relevance in the field of software development is difficult to overestimate. They are particularly popular in the developer community, leading to the creation and publication of new patterns for specific tasks. And in these conditions, a reasonable request arises – how to make sure that the architectural solution proposed by someone actually solves the tasks assigned to it? How and on the basis of what to validate patterns? This paper will cover this issue.
Before checking the pattern, it is important to understand that any pattern, as mentioned earlier, is not a heuristic or an abstraction for the sake of abstraction. The whole essence of patterns is in solving the task, which implements the requirements imposed on the system and which leads to an increase in the metrics of certain attributes of the quality of architectural solutions [2].
Pattern validation is undoubtedly important, yet it presents its own challenges and problems. Some point to a lack of research despite the widespread popularity of using patterns and certain validation attempts that have focused on specific areas of their application [1]. Also, the ambiguity of the approach to template checking is emphasized. [1]. In addition to this very ambiguity, there are also various difficulties that accompany almost any validation process. For example, it has been observed that the quality of requirements directly impacts the effectiveness of validation [3]. Difficulties in checking for compliance may be related to the incompleteness or inconsistency of these very requirements. Additionally, the human factor and lack of experience can also lead to validation problems [3].
Despite the problems, validation still has its own special place in design. Any pattern is part of the architecture for which, for example, 4 validation methods can be distinguished, namely: technical review, perspective based inspection, checklist-based inspection and Fault Tree Analysis (FTA) [4]. These methods can be used to a certain extent for patterns. However, this is not the only possible approach. The methods used in the validation sessions are also highlighted (an interactive pattern workshop, pattern checklist) [1]. They allow you to get important information to improve the quality of patterns. Furthermore, in the community of developers themselves, it is proposed (as a method) to bring it up for discussion with experts in order to receive feedback from them [5]. For this purpose, you can use seminars, interviews, diagrams, prototypes – anything that will help convey ideas to interested parties. As a result, there is also an opinion that the pattern in its early stage is most effectively validated by open discussion, qualitative data, and an analytical approach, whereas a more mature one already needs quantitative expert feedback [1].
Now let's look at the existing research, despite the above problems. Some of them consider when it is useful to use certain patterns. The results indicate their validity when it is used in such a way that it corresponds to the problem. Each design pattern has its own nature, the right place and conditions of use and, as a result, validity depending on the context [6]. Also, do not forget what place software quality attributes occupy. Numerous relevant researches for the validation of patterns and their empirical study show the existence of a significant relationship between the use of design patterns and the quality of the result [7]. For example, the impact of patterns on reusability, flexibility, and clarity. In addition, there are studies that demonstrate an increase in program efficiency and development productivity by 25-30% due to the use of correct patterns [8]. This is all despite the fact that some note a lack of research, as mentioned earlier. However, it can be characterized by the fact that some studies are focused on validating only part of the criteria for patterns. For example, one of the studies [9] examines the effect of GoF on the stability of certain classes. In another study, only security patterns were taken [10] and, accordingly, they were considered only from one side. But there are also some contradictions here. In mentioned studies, as well as in a series of others, it is concluded that developers should use design patterns to improve the quality of software. But at the same time, other studies suggest that design patterns prevent the achievement of the required level of quality of the subject software [2].
Undoubtedly, design patterns occupy a special place in the software design process and in development in general. They allow developers at all levels to take advantage of best practices in specific areas, saving resources and getting a solution that meets all the necessary quality attributes. Their validation also occupies a special place. There is a whole list of different methods for this. At the same time, the development community relies on experiments, real-world use and expert opinion, since there are many factors that can affect the quality of research, as evidenced by the presence of problems in this area and contradictions among researchers. In my opinion, design patterns still need to be checked in two stages. First analytically using formalisms and peer review to collect metrics and feedback. After that, when the elaboration of the pattern is brought to the final version, it is the empirical approach that begins to play an important role. This is due to the fact that there are countless contexts of use and only in practice and a quantitative approach it is possible to identify all the features of the pattern, its versatility and check it for compliance with the stated criteria in a real environment. And, probably, the most important thing is that the patterns must be used correctly! Accordingly, then their correct validation will be possible.