20/05/2015Dr Andy Brooks1 MSc Software Maintenance MS Viðhald hugbúnaðar Fyrirlestrar 19 & 20 The Benefits of Design Patterns

20/05/2015Dr Andy Brooks2 The Blob antipattern The Blob is an antipattern: an object with too many variables and methods. The solution is to refactor and reallocate behaviour away from the Blob.

20/05/2015Dr Andy Brooks3 The Façade Pattern Context –A client´s relationship with a subsystem is far too complex. –The client does not wish to deal with all the details of the subsystem. Solution Client Façade UML class diagram

20/05/2015Dr Andy Brooks4 Façade Pattern Consequences The subsystem is easier to use. Façade clients don’t need to know about classes behind the façade. –reduced coupling Maintainer can ‘easily’ add new façade clients and ‘easily’ change the implementation of the classes behind the façade, whilst preserving the interface to the façade. Façade clients are not prevented from using subsystem classes directly if they really need to. –but best avoided to minimise coupling

20/05/2015Dr Andy Brooks5 The Singleton Pattern This pattern is used to ensure a class has only one instance and to provide a global point of access to it. Andy says: the benefits to the maintainer are not obvious after the pattern is implemented and being used. Pattern In Version A Of The System

20/05/2015Dr Andy Brooks6 The Factory Pattern Context – A class knows it has to create a number of different types of objects but can´t always anticipate the class of each object. Consequences –Eliminates the need to bind to specific classes. If other kinds of objects need to be created, the maintainer´s job should be ‘easier’. Pattern In Version A Of The System

20/05/2015Dr Andy Brooks7 Reference OO Design Patterns, Design Structure, and Program Changes: An Industrial Case Study, James M Beiman, Dolly Jain, and Helen J Yang, Computer Science Department, Colorado State University, Fort Collins, Colorado USA CSM01.pdf Case Study Dæmisaga

20/05/2015Dr Andy Brooks8 “OO design patterns are especially geared to improve adaptability, since patterns generally increase the complexity of an initial design in order to ease future enhancements. There is little empirical evidence to support claims of improved flexibility of these preferred structures. We want to determine the relationship between design structures and external quality factors such as reusability, maintainability, testability, and adaptability.” Bieman et al.

20/05/2015Dr Andy Brooks9 Design Structure And Software Changes Design structure is assessed by class measurements (e.g. size) and participation in inheritance relationships and design patterns. Changes are measured by counting the number of times a class is modified over some time interval.

20/05/2015Dr Andy Brooks10 The Commercial OO System Version control system provides data for 39 versions of a commercial OO system (C++). Version A is the first stable version: –199 classes, ~ 24,000 lines of code Version B is the final version in the captured data set: –227 classes, ~ 32,000 lines of code The 191 classes that appear in versions A and B are the focus of the study.

20/05/2015Dr Andy Brooks11 Hypotheses H1: “Larger classes will be more change prone.” –more functionality, more likelihood of change H2: “Classes participating in design patterns are less change prone.” –changes should be made through the use of subclasses or new participant classes H3: “Classes that are reused through inheritance will be less change prone.” –it is usually difficult to modify a class which has many descendants tilgátur

20/05/2015Dr Andy Brooks12 Metrics Total number of attributes (TotAtt) and total number of operations (TotOp) Number of friends methods (Friends) –The friend mechanism allows a class to grant access privileges to other classes or functions. Number of overridden methods (MO) Depth of inheritance (DOI) –base class has a DOI of zero Number of direct child classes (DCC) Number of descendants (Desc)

20/05/2015Dr Andy Brooks13 Metric Values for Version A 191 classes Changes counted in going from Version A to Version B. Most distributions are not normally distributed: the mean and median values are quite different for several metrics.

20/05/2015Dr Andy Brooks14 Types Of Changes Changes can be corrective, adaptive, enhancement, or preventive. Bieman et al state that the analysis found no significant differences between the different types of change. Andy says: it would be useful to know the details of this analysis, particularly the distribution of change types with repect to pattern and non-pattern classes.

20/05/2015Dr Andy Brooks15 Finding Intentional Patterns In The Code 1.Pattern names searched for in the documentation. 2.Identify classes associated with the patterns identified in 1. 3.Verify implementations are patterns. 4.Verify that the classes and relations in a pattern have the same purpose as described by an authorative reference Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et al, Addison-Wesley, 1995

20/05/2015Dr Andy Brooks16 Patterns Found In Version A PatternNumber of Instances Singleton10 Factory Method1 Proxy1 Iterator4 18 classes played a role in 16 pattern instances. There were 4 different implementations of singleton: only one of these implementations exactly matched the specification of the singleton pattern by Gamma et al.

20/05/2015Dr Andy Brooks17 Metric Correlations With Number Of Class Changes Size correlates with the number of changes. Data is not normal, so it is better to focus on the Spearman Rank Correlations.

20/05/2015Dr Andy Brooks18 H1: “Are Larger Classes More Change Prone?” The null hypothesis can be rejected and H1 accepted: large classes are more change prone.

20/05/2015Dr Andy Brooks19 H2: “Are Pattern Classes Less Change Prone?” 75% of non-pattern classes are changed at most once. Classes in patterns require more changes. But are classes in patterns larger? Boxplots The box is the middle 50%. Line in box is median.

20/05/2015Dr Andy Brooks20 Total Operations And Pattern Participation Pattern classes are larger. But data has to be normalised with respect to class size.

20/05/2015Dr Andy Brooks21 Change Density And Pattern Participation Removing the outlier gives a clearer picture. Pattern classes are more change prone. The null hypothesis for H2 cannot be rejected. 191 classes190 classes

20/05/2015Dr Andy Brooks22 ¬H2: “Classes Participating In Design Patterns Are More Change Prone” Data is not normally distributed, so apply a non-parametric test. A Mann-Whitney test (of the equality of two population medians) rejects the null hypothesis with a p = Concluded that classes participating in design patterns are more change prone.

20/05/2015Dr Andy Brooks23 H3: “Are Classes That Are Reused Through Inheritance More Often Less Change Prone?” The correlation analysis indicates that classes with more children (DCC) or more descendents (Desc) are changed more. –The coefficient of 0.29 is not big. Bieman et al conclude that classes reused through inheritance are not less change prone.

20/05/2015Dr Andy Brooks24 Analysis Of Covariance The analysis revealed that TotOp and Pattern are significant predictors of the number of changes. –Friends, DCC, and Desc are not significant predictors. Also, TotOp has a much greater effect than pattern participation. No interaction effect was found between TotOp and Pattern.

20/05/2015Dr Andy Brooks25 Analysis Of Covariance The analysis resulted in the following models: –Non-Pattern Classes Changes = 0.352(TotOp+1) 0.91 – 1 –Pattern Classes Changes = 0.526(TotOp+1) 0.91 – 1 The models maintain a constant ratio between non-pattern classes and pattern classes as the number of operations increase. –Pattern classes suffer half as many changes again ,176 = 0,528

20/05/2015Dr Andy Brooks26 Friends Friends were correlated with changes but the coefficient is only Friends was not significant in the analysis of covariance. There were very few classes with friend operations. “Additional data is needed to evaluate the effect of friend functions on change proneness.”

20/05/2015Dr Andy Brooks27 Depth Of Inheritance (DOI) Trend? The trend disappears when class size is accounted for by using change density. (without outlier)

20/05/2015Dr Andy Brooks28 Design Pattern Benefits “We also found that the designers used variants of Singleton that may have made it more difficult for maintenance programmers to adapt these classes. Thus, the benefit of using design patterns is realized only if the actual changes match the ones supported by the patterns in the system. Thus, one reason for our results may be that the use of design patterns was detrimental, because the actual changes did not match the patterns that were put in place in the earlier version.” ***

20/05/2015Dr Andy Brooks29 Construct Validity Are you really measuring what you think you are measuring? Count of changes is an intuitive measure of maintenance effort. But all changes are not equal. –Unfortunately change effort data was not available for this study. Averaging over a large number of changes over a series of 39 program versions hopefully mitigates the effects of variability in change effort. Threats To Validity

20/05/2015Dr Andy Brooks30 Content Validity Are your measures adequately sampling the domain? Count of changes is only one aspect of the maintenance effort. –What about design, implementation, and testing effort of making the changes? The metrics and pattern data capture the notion of design structure but there is no known set of metrics and patterns which completely capture design structure. Undocumented patterns were not identified. Threats To Validity

20/05/2015Dr Andy Brooks31 Internal Validity Is there a genuine cause and effect relationship? Do the dependent variable(s) really depend on the independent variable(s)? –If subject ability is not carefully randomized, ability effects may be the cause and effect relationship in the experiment. Statistical results of themselves are not proof of causality. Causal explanations were provided as a basis for the hypotheses, but these explanations are not formal theories. Threats To Validity

20/05/2015Dr Andy Brooks32 External Validity Can the results be generalized? The results here are based on a single application which may not be representative of all software maintenance. The developers may have had inadequate knowledge of patterns and they might not be representative of developers experienced in pattern usage. Undocumented patterns were not identified and the results for the patterns identified may not represent all pattern usage. Threats To Validity

20/05/2015Dr Andy Brooks33 Conclusions Bieman et al Number of changes can be predicted from class size (number of operations). Design patterns do not support adaptability. –An informal analysis of the system indicates classes involved in patterns provide key system functionality, which might explain why they were change prone. Andy says: it would be useful to know the details of this analysis and what changes to key system functionality were being made.

20/05/2015Dr Andy Brooks34 Conclusions Bieman et al Classes reused through inheritance tend to be changed more. –A change in the superclass effectively means a change to all descendants which increases the effort needed for regression testing. Further studies needed to generalise findings. “We are now working to identify key reasons for the counter-intuitive results.”

20/05/2015Dr Andy Brooks35 The Other Classes What about the classes in Version B which are not in common with Version A. Were they involved in the patterns identified in A? Were they concerned with the introduction of more patterns?

20/05/2015Dr Andy Brooks36 What Are the Benefits To Maintenance? Anyone attempting to replicate this case study in another company would be advised: a)to make clear statements about the anticipated benefits to maintenance of using particular design patterns b)collect data to determine if maintainers actually exploit the benefits claimed by the patterns