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

18/04/23 Dr Andy Brooks 1

MSc Software MaintenanceMS Viðhald hugbúnaðar

Fyrirlestrar 19 & 20The Benefits of Design Patterns


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.

www.antipatterns.com


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.

• SolutionClient

Façade

UML class diagram


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


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


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


ReferenceOO 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 80523 USAhttp://www.cs.colostate.edu/~bieman/Pubs/BiemanJainYangICSM01.pdf

Case StudyDæmisaga


“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.


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.


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.


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


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)


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.


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.


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


Patterns Found In Version APattern Number of Instances

Singleton 10

Factory Method 1

Proxy 1

Iterator 4

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.


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.


H1: “Are Larger Classes More Change Prone?”

The null hypothesis can be rejected and H1 accepted: large classes are more change prone.


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.


Total Operations And Pattern Participation

• Pattern classes are larger.• But data has to be normalised with respect to class size.


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 classes 190 classes


¬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 = 0.0003.

• Concluded that classes participating in design patterns are more change prone.


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.


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.


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.

0.352 + 0,176 = 0,528


Friends

• Friends were correlated with changes but the coefficient is only 0.38.

• 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.”


Depth Of Inheritance (DOI) Trend?

• The trend disappears when class size is accounted for by using change density.

(without outlier)


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.”

***


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


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


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


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


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.


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.”


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?


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

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

Documents

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