Influence of Design Patterns Application on Quality of IT Solutions

Influence of Design Patterns Application on Quality of IT Solutions NADINA ZAIMOVIC, DZENANA DONKO Department for Computer Science and Informatics Faculty of Electrical Engineering, University of Sarajevo Zmaja od Bosne bb, Kampus Univerziteta, 71000 Sarajevo BOSNIA AND HERZEGOVINA nzaimovic@etf.unsa.ba, ddonko@etf.unsa.ba Abstract: - Previous studies have shown that the design patterns contain or support the principles of Object Oriented Design (OOD). Design that contains the principles of design is considered to be high quality design, and such a design should be flexible and easy to maintain and upgrade, which is very important for business solutions. Quality of design is measured with Object Oriented (OO) metrics, which indicate the weak points of design, such as high dependency, unnecessarily large inheritance hierarchies and similar malicious relations. Simulating change requirements on a simple business software solution, this work analyzes the impact of design patterns in a software quality in the context of changeability and basic features and principles of good OOD. Object Oriented metrics evaluation gives measurement of the impact of the used patterns and shows whether design patterns quantitatively increase software quality. Key-Words: - Object Oriented Design, design patterns, Object Oriented metrics 1 Introduction The development of information technologies and tools that enabled the implementation of almost any user requirements, has led to a shift of focus of research and work from achieving the functionality of software solutions to the quality of design that will provide ease of maintenance and upgrades. Conform to the principles of OOD leads to a flexible solution suitable for the change, but how to achieve that design, without much experience in OOD is still a question. Design principles are focused on the management of dependencies between classes and objects, because high dependency is the main cause for maintenance and upgrade problems of existing systems [3]. With design principles being more theoretical foundation and goal of development, many authors introduced a strategies as a practical guidelines for implementing the principles that primarily lead to a ready to change and maintainable code [1][2]. OOD principles assure quality, flexibility and convenience for software maintenance [3]. At the same time the design that follows strategies described above leads to the solution that is ready for upgrades and modifications [1][2]. Design patterns, as already proven solutions to common design problems, in its class and dependencies structure contain or implement the principles of design [4][9]. That would lead to the conclusion that they contribute to quality of design [8]. However, we still have discussions about whether this is indeed the case and are design patterns themselves make better design quality and remove unnecessary dependencies, reduce the number of classes and change difficulties, or do they lead to greater number of classes and fuzzy code. Application of object-oriented metrics gave unexpected results: the result factors for solution with patterns were worse than factors with no patterns [4][8]. The question is whether the problem is in the design patterns or metrics themselves. In order to answer this question, this paper approaches general analysis, which includes: A descriptive analysis of patterns application in implementation of change requirements to the existing simple solution for BuyCar system - a system for selling vehicles at an auto dealership, that will show the impact of design patterns on current and future changes in the system. Compliance of solution with and without applying patterns to the principles and strategies of design., Quantitative analysis with OO metric evaluation to solutions. 2 Characteristics, Principles and Strategies of Good Design Analysis of the impact of design patterns in software development solution determines if solution without and with a design pattern has the basic qualities of good design, whether it is in line with the ISBN: 978-960-474-317-9 94

principles of OO design, and that it respects the basic strategies that provide quality. Basic characteristics of a good OO design are high level of cohesion and low level of dependencies, which indicate good class organization and low dependency of the system [7]. A high level of cohesion - class must contain attributes and operations are important only for its primary responsibility Low level of dependency - Classes should be less dependent and interrelated 2.1 Design principles in relation to which the analysis is performed The principles of OO design shows the correct direction in design and help to avoid costly mistakes in the design phase. Analysis of the quality of design will be carried out in relation to the following principles [3][5]: Open Closed Principle (OCP): Software entities (classes, module, function) should be open for extension but closed for modification. Single responsibility principle (SRP): Class should have only one reason for the change. Liskov substitution principle (LSP): Subclasses should be substitutable for their base classes. Dependency inversion principle (DIP): Depend upon abstractions. Do not depend upon concretions. The Interface Segregation Principle (ISP): Many client specific interfaces are better than one general-purpose interface. 2.2 Design principles in relation to which the analysis is performed Basic object-oriented design strategies provide guidance to achieve true measure of the use of encapsulation, inheritance, composition and delegation. These strategies have been recognized as a technique for building code that is reusable and easy to change and maintain. Basic guideline in these strategies is the code ready to change, so they are summarized by the following [1][2][7] : Interfaces over implementation: The variables should be related to abstract classes, interfaces, and not for concrete implementation. This will reduce the implementation dependencies between classes and subsystems. Composition over inheritance: Wherever is possible it is necessary to prefer composition over inheritance, which achieves a new functionality by combining a objects instead of changes in several existing classes basic and derived. Encapsulation of changes: Encapsulation of code that is prone to changes will ensure isolation of changes in the minimum number of class. 3 Analysis of the Design Patterns Impact For the purposes of analysis we have taken a simple business system BuyCar, which is assumed to have basic modules for sales, procurement and personnel records. The assumption is that the system already has a basic functionality classes like orders, payments, employee, client, etc. To analyze the quality of design solutions in the context of readiness to change and upgrade, we assume that we obtained new requirements for the following functionality: Module personnel records should provide a consistent and legally correct application of employees from different states with different types of contracts Enable adding additional equipment at the basic passenger or transport vehicles, such as air conditioning, sports seats, etc. 3.1 Analysis of design patterns application to the personnel records module In traditional, non-pattern implementation of the personnel records module it is assumed that we have a base class Employee and derived class for every type of employees who have a different calculation of salaries and contributions, and proper object instance will be created within the class PersonnelRecords that acts. as a client class. Such a setting would lead to the class structure shown in Fig 1. Fig.1. PersonnelRecords module without patterns We can see that the creation of certain types of ISBN: 978-960-474-317-9 95

employees unstable segment of the design that makes the class PersonnelRecord instantiating concrete objects, and then calls methods of application and calculation of employee salary and contributions. This indicates the possibility of use of one of creational design patterns. By applying the Factory Method pattern, the existing structures of class will be replaced by the structure shown in Fig. 2. By analyzing the design of the first and second solution in relation to the above features, strategies and principles, we can make conclusions shown in Table 1. shortcomings of the first and advantages of the second in the context of design quality and readiness for change. Solution A no pattern Violation of the dependency inversion principle (DIP): In the case of the first solution, with no patterns we can see that PersonnelRecords class directly instantiating objects of all types of employees. When you instantiate an object you create a dependency on a particular class, which violates the DIP. Violation of the open closed principle (OCP) With this class structure any change in concrete class can lead to changes in the class of personnel records. In addition, in the case of a request for a new type of employee, e.g. part-time workers or in the case that some types of employees are abolished, changes would affect Personnel Records class. That would mean permanent changes to the if / else section of code within this class. Un changes encapsulation strategy As last observation showed unstable part of code is not encapsulated and solution is not easy to maintain or upgrade in the event of a change request or business policy. Solution B Factory Method pattern Applying the principles of dependency inversion (DIP): With Factory Method pattern it is achieved that the high-level class (Personnel Records) does not depend on low-level classes (types of employees), but on the abstraction that is achieved through the Factory Method. Using patterns, Personnel Records now depends only on the abstract class of employee, because thanks to the Factory method, does not know what kind of employees will be created, or create them itself. Fig.2 PersonnelRecords module with design patterns 3.2 Analysis of design patterns application to the the Sales module Equipment Use of inheritance is common when we need to add a new feature of the entities, so with traditional design we would make a new class to add equipment to basic vehicle. This approach would lead to the class structure shown in Fig 3. It is obvious that the introduction of each new element enhancement leads to a new class of performance, and therefore with a greater number and combination of equipment and an explosion of class. With each new class, it is necessary to amend the method for calculating prices and descriptions within the new class. By changing the price or description of some of the elements, it is necessary to modify the method in each class whose price includes the cost of equipment provided. By using the Decorator pattern, which allows the dynamic addition of properties of objects to the initial object by wrapping the new facilities, class structure from Fig 4. is created. This way the solution is designed to be fully prepared for new changes and new equipment elements. For every new feature we need to add a new derived class of EquipmentDecorator class and implement its methods for price and description. Analysis of the first and second solution demonstrates the Applying the open closed principle (OCP): With request for adding a new employee type we can see this solution does not require changes in high-level class, modification is localized and functionality update is enabled by adding new classes and their instances through the one of Factory Method factories. Applying changes encapsulation strategy As we have seen, instantiation of concrete objects is is an area of potential change, and the creation of objects is now encapsulated in a separate class. Applying interfaces over implementation strategy With this solution Personnel Records class does not depend on concrete classes of employees, but just on abstract class Employee Table 1. Analysis of results for two strategies for PersonnelRecord module Fig.3 Sales module Equipment without patterns ISBN: 978-960-474-317-9 96

Following this approach, applying traditional design and design patterns for same functionality, similar conclusions have been achieved for the remaining three modules analyzed for this work. Final conclusions derived by analyzing these class structures and the code itself in the context of new change requests are presented in Table 3. Fig. 4 Sales module Equipment with pattern Solution A no pattern Violation of the open closed principle (OCP) This solution violated the open-closed principle, because the base class is open to new changes and the changes are made in its code in case any new requests for adding or deleting additional equipment. Violation of the single responsibility principle (SRP) The client class Offer violates the principle of single responsibility, since it must first take care of creating the appropriate set of objects, and then manipulate them.mean permanent changes to the if / else section of code within this class. Solution B Decorator pattern Applying the open closed principle (OCP): New solution conforms the open-closed principle as the base class remained at an abstract level, expansion is allowed, but not the changes. Now we see that in the case of adding new equipment, it is enough to create a class for new equipment and to implement it, while on the base class, as well as classes for the models or the rest of the equipment, there will be no change. The same is the case if some of the equipment is withdrawn from the offer. Applying composition over inheritance strategy With pattern, using composition and delegation made unnecessary inheritance avoided and enabled functionality extending during the code execution. Even addition of new elements and equipment in the next phases is enabled without adding new levels of hierarchy. Table 2. Analysis of results with/without pattern 4 Object Oriented (OO) Metrics Evaluation In order to determine the quantitative effect of applying design patterns to the quality of software solutions, we some of the OO design metrics at the individual modules of the system, with and without design patterns. Metrics are generally at the global level and calculated for an entire system, to indicate the weak points of the design and provide general recommendations for improvement [6]. Design patterns, on the other hand, operate at the local level, they are usually to segments of the design and they show how to solve problems like tight coupling or other deficiency of design [6]. For this reason, we apply metrics and the rest of the analysis on individual modules. Design patterns have different purposes and they are used in specific situations. Most design patterns aim to reduce coupling and dependencies and increase the cohesiveness of classes, while others give recommendations for optimal class hierarchy and other design features. This is reason, why a limited set of metrics is on specific modules of system. For this analysis we have calculated some of metrics factors for design solution without design patterns (referred as Solution A) and for design solution with design patterns (referred as Solution B). The used metrics are Weighted methods per class (WMC), Depth of inheritance tree (DIT), Number of children (NOC), Method Inheritance Factor (MIF), Coupling Factor (CF), Polymorphism Factor (PF) [8][10]. The models accuracy can depend on type of metrics [11]. 4.1 Personnel records module - Evaluation of Factory Method pattern application Table 4. presents results od evaluation for application of Factory Method pattern. In calculating CF factors when calculating the total number of possible connections or dependencies, derived class is not taken into consideration. However, the analysis of the implementation of this module has shown that the class Personnel Records really depends on each individual derived class, they are taken into account when calculating the CF before applying patterns. It was demonstrated that the pattern has contributed to reducing dependencies within this module. As it can be seen from the presented results, there was no significant difference in the quality of solutions measured before and after the application of patterns, except from the point of coupling, which both metrics show that is approved. As for the metrics that indicate the possibility of reuse of code, both PF and MIF factors showed no significant changes, only a small difference due to the introduction of a new level of the hierarchy. ISBN: 978-960-474-317-9 97

Factory Method OOD principles OOD strategies OOD characteristics - DIP, OCP Encapsulation of changes Tight coupling + DIP, OCP, LSP Encapsulation of changes Loose coupling Abstract Factory - DIP,OCP, SRP Composition over inheritance Low cohesion Tight coupling + DIP,OCP, Composition over inheritance Strong cohesion SRP,LSP Interfaces over implementation Loose coupling Encapsulation of changes Decorator - OCP, SRP Low cohesion + OCP, LSP, DIP Composition over inheritance Strong cohesion Facade - OCP, SRP Tight coupling + OCP, SRP Encapsulation of changes Loose coupling CoR - OCP Tight coupling + OCP, DIP, LSP Loose coupling Table 3. Analysis results for all five modules CBO MIF PF CF A B A B A B A B Employee 1 1 0 0 0 0 1 1 EmployeeFixedCalc_StateA 0 1 0,8 0,8 1 1 1 0,5 PersonnelRecords 7 3 0 0 0 0 1 0,15 PersonnelStateA / PersonnelStateB - 3-0,75-0,5-0,43 Table 4. Evaluation of Factory Method pattern application DIT NOC CBO MIF PF CF A B A B A B A B A B A B Offer 0 0 0 0 1 1 0 0 0 0 0,5 0,3 Vehicle 0 0 2 3 1 1 0 0 0 0 0,5 0,6 Delivery/Passenger 1 1 3 0 0 0 1 1 1 1 0 0 PassengerAirCond/PassengerNavig/Passenge 2-0 - 0-1 - 1-0 - rsportseats DeliveryAirCond/DeliveryrNavig/DeliveryS 2 - - - 0-1 - 1-0 - portseats AirCondition/Navigation/SportSeats - 1-0 - 0-1 - 1-0 EquipmentDecorator - 0-3 - 0-2 - 0,5-0,3 Table 5. Evaluation of Decorator patern application 4.2 Sales module Equipment- Evaluation of Decorator pattern application As previous analysis of Decorator pattern application has shown, this pattern primarily affects the hierarchy of classes and the flexibility of the subsequent changes. Associative relations and coupling are not problematic segment of this module, but inheritance relations, whose number would grow rapidly with each new element added in company s offer. We can conclude that the metrics that have been do not show the actual changes that occur with the application of this pattern, and that only through DIT and NOC factors that indicate good or poor class hierarchy, we can see that there was a positive impact. This impact would be even more obvious if we added a few more elements of equipment to a change request. With each new element NOC factor would increase - the number of derived classes for vans / passenger vehicles, which leads to changes of each method for calculating the price and description of the selected vehicle, and also we can predict growth of DIT factor deriving classes which are combinations of elements. On the other hand, in solution B, the one with design patterns, only to change NOC factor of EquipmentDecorator class would increase with these, while all the others would remain with the same value. ISBN: 978-960-474-317-9 98

5 Conclusion As analysis has shown, design patterns contain OO design principles, include the basic characteristics of good design, and implement the basic strategy for the development of good OO solution. This makes solution easier to change, which allows maximum reuse of code and minimal changes to existing classes in implementing future requests On the other hand, design patterns usually involve creation of new, additional classes with no role in the system, which leads to more code, a large number of classes and often complex solutions as shown in [5] and our analysis. As the analysis of the solutions in the context of the requirements change showed pattern solution is more flexible and easier to maintain, it can be concluded that the additional flexibility comes at a price, which is usually reflected in a number of classes, deeper hierarchies and similar features that the traditional measurement metrics lead to the same or worse results We conclude that the global results of the metrics are not sufficient indicator of the design patterns impact on quality, as they observe the system at the global level and do not consider the details of design, neither the importance of low coupling and loose cohesion of the individual, most important classes of system in relation to others, individual classes that deal only additional requirements. Focusing on individual segments of design that are highly affected by requirements changes and analyzing specific metrics factors, that indicate the design problem in such situations, made us conclude that the design patterns do improve the software development process and software design quality, as long as they are used in situations for which they are intended. Recommendations on use of specific design patterns in usual business requirements for optimal design quality for no experienced designers is our scope of future work and research. References: [1] E.Gamma, R.Helm, R. Johnson, J. Vlissides, Design Patterns, Elements of Reusable Object- Oriented Software, Addison-Wesley Professional, 1995. [2] A. Shalloway, Design Patterns Explained: A New Perspective on Object-Oriented Design, Addison-Wesley Professional, 2004. [3] R. C. Martin, Design Principles and Design Patterns, www.objectmentor.com, 2000. [4] C. Pescio, Principles Versus Patterns, Software Technology magazine, 1997. [5] J. Garzás, M. Piattini, Analyzability and Changeability in Design Patterns, 2nd SugarLoafPLoP Conference, Rio de Janeiro, Brazil, 2002 [6] B. Huston, The effects of design patterns application on metric scores, Journal of Systems and Software, 58(3): 261-269 (2001) [7] B. Mclaughlin, D. West, G. Pollice, Head First Object-Oriented Analysis and Design, O'Reilly Media, 2006. [8] F. Abreu, W. Melo, Evaluating the Impact of Object-Oriented Design on Software Quality, Proceedings of the 3rd International Software Metrics Symposium, 1996. [9] J. Garzás, Mario Piattini, From the OO Design Principles to the Formal Understanding of the OO Design Patterns, OOPSLA 2001 Workshop, Beyond Design: Patterns (mis)used. Tampa Bay, Florida, USA. [10] S. R. Chidamber, C. F. Kemerer, A Metrics Suite for Object-Oriented Design, IEEE Trans. Software Eng., vol. 20, no. 6, June 1994, pp. 476-493. [11] S.S. Rathore, A. Gupta, Investigating objectoriented design metrics to predict faultproneness of software modules, 2012 CSI Sixth International Conference on Software Engineering (CONSEG), 2012, Page(s): 1-10 ISBN: 978-960-474-317-9 99