Pages Menu
Categories Menu

Posted by on Feb 25, 2013 in General | 1 comment

What is the value of a software design pattern?

All things are poison and nothing without poison; it is only the dose that makes something not poisonous. With this famous quote the physician and alchemist Paracelsus, father of modern toxicology, tells us that the amount of a substance is as important to a patient as the nature of that substance. A small dose of aspirin can be beneficial to someone, but at very high dose, this common medicine can be deadly for that same person.

In the same sense, a small dose of design patterns can be beneficial to software design, but in very high dosage, it can be fatal. At present, however, we do not know how many patterns we should apply or what the value of a design pattern is. Most current software engineering practice and research is done in a value-neutral setting, in which every requirement, use case, object, test case, and design pattern is equally important [1].

Note too how this has brought about great differences between theory and practice in software engineering. It has also highlighted the danger of following trends and of thus becoming a ‘software lemming’ [2], where we see how someone contributes with a great design solution and then everybody rushes to apply it. In this sense, the software design field has been contributing to the creation of good solutions for improving software quality design for some time, but without stating the value of any quality item. As [3] says, if you do not understand basic principles of economics, many management decisions inflicted on you might appear to be mere rolls of the dice or the wrath of angry “gods.” Cost effectiveness is one of the important issues when developing products in a life cycle.

For reasons like these, a value-based software engineering (VBSE) agenda has emerged [1], whose goal is to integrate value considerations into the full range of existing and emerging software engineering principles and practices. One of the major elements of this agenda is Value-based architecture, which involves a further reconciliation of the system objectives with achievable architectural solutions. Value-based design and development also involves techniques for ensuring that the system’s objectives and value considerations are inherited by the software’s design and development practices.

What we have outlined above gives the background to the present paper, which deals with different issues related to design patterns, their value, and the quantitative benefit they bring to a specific design.

The remainder of this article is organized as follows: Section 2 illustrates the problem of neutral value of design patterns; Section 3 outlines the value-based application of design patterns; a method for calculating the value of a design pattern is presented in section 4. Section 5 shows an example of application of value-based design quality. Section 6 shows a practical case. Finally, we present the conclusions drawn, along with future work; these are set out in section 7.

1. The problem of the neutral value of design patterns

To guide the improvement of a software design, software engineers use the enormous amount of practical knowledge accumulated by the community of designers [4]. This is knowledge that is very valuable and useful.

The situation today is that we have the knowledge, but we do not know the particular value of each one of the elements of that knowledge. An additional factor to be kept in mind is that the large amount of work in improving software design is done in a value-neutral setting, in which each pattern or design rule is treated as equally important.

If you know the design patterns, you can apply one, or many, in one or many problems in your design. There are many methods for the detection or introduction of patterns. Like most current software engineering methods, however, these ones are similarly value-neutral; as a rule, this kind of method assumes that each design pattern is equally important.

Considering all this, it is hard to justify costly investment in design or re-design and it is equally difficult to make major design decisions confidently. The importance of the issue is patently clear when we are planning the improvement of software architecture and we do not know which solution has the highest value, how many improvements are enough, and so on.

Design patterns would improve a software design, but designers have not had the sense or ability to analyze the situation quantitatively, or to frame it in such a way as to be compelling to business decision-makers.

We do not know the value of patterns; hence, we do not know what quantities of them are reasonable, or, in other words, we are not able to see what dose makes a design non-poisonous.  On many occasions, when designers need to improve a design, the most intuitive way is to detect the deficiencies and fix a percentage of deficiency resolutions. This neutral value method has many problems. We have seen how the extreme use of design patterns, or the phenomenon of “over-pattern”, imply several maintenance problems [5].

2. Foundations of the value-based application of design patterns

In a value-based design approach we need to know which design patterns are the most expensive to apply, what patterns have the greatest value, the ROI of applying each pattern, and so on.

The value-based approach also provides a framework for determining which low-risk, dynamic parts of a project are best addressed by more lightweight, agile methods and which high-risk, more stabilized parts are best addressed by plan-driven methods. Such syntheses are becoming more important as software becomes more product-critical or mission-critical, while software organizations continue to optimize on time-to-market. There are too few works that deal with these matters.

The first important issue about value and design patterns is that we should be conscious that each pattern has a different value for our particular design. Moreover, not only are there different values among the different kinds of patterns; there are different values among the same kind of patterns according of its concrete place of application.

Let’s consider a design that has a problem with a “cron job” [1]. The cron job sends a message to five design classes on a daily basis. This can be a maintenance problem, since if we need add any particular design class more, we need to modify that class’s cron. At this moment in time we believe that the application of the observer [6] pattern will have a high value, since each time that we need add another class we will save maintenance time; but:

–     What happens if this cron never has to be changed?

–     What about the cost of refactoring our design to introduce this pattern?

–     Is this pattern more valuable than any other solution, and how much more?

–     Even if the same pattern could be applied in several design locations, is it of equal value in all cases?

Solving these questions is fundamental if we are planning redesign on a large scale. Planning that is guided by the percentage of design patterns to be applied, without knowing the value of any pattern, can reach no optimal situation. The most optimal situation is a Pareto distribution in which 80% of the mission value comes from 20% of the patterns used. A straight-line curve is the usual result of a project for software design improvement in which the next rule is equally likely to have either a low or high business value.

The above consideration is also basic when calculating the return of investment (ROI) of the design refactoring. It is essential if we want to get away from a neutral-based approach.

3. A method for calculating the value of a pattern

Patterns can add different kinds of value according to the particular phase of the software life cycle in which they are considered. The proposed method estimates the value of design pattern for the maintenance of an existing design.

As regards maintenance, we propose that the value of a design pattern_n come from the value of introducing it in design place_m, taking into consideration the following parameters:

–     PROBABILITY OF CHANGE OCCURRING (PLACE_M). It is the probability of a change having to be brought in to the part of the design, or design_m, where pattern_n could be introduced. This is important, since we could have a design that may never be changed; in this case, introducing the patterns would be a cost without any ensuing benefit.

–     COST OF INTRODUCTION (PATTERN_N, PLACE_M). This is the estimated cost of implementing the design pattern (pattern_n) in a given design (place_m). It is mainly the cost of refactoring the design so as to put the pattern in place. This cost is usually measured in person-hours.

–     COST OF LOSS IF CHANGE OCCURS (PLACE_M). This is the cost impact if change occurs. On the other hand, how much cost (in person-hours, for example) we can save if we introduce the pattern.

Once we have completed the cost of introduction, probability, and cost of loss, we can know the value of introducing a pattern, see Table 1. The equation of Table 1 is an adaptation of the issues for the traditional risk exposure equation to make them applicable to software design and value. In general terms, risk exposure of any given risk = probability of risk occurring x total loss if risk occurs. The higher results for “value of introducing a pattern” indicate a greater priority as regards application.




Table 1. Value of introducing a pattern

A problem that arises when you have a number of possible patterns to apply is that it can be difficult to decide which are worth putting effort into addressing. The value of introducing a pattern is that it provides a simple calculation that gives a numerical value, which could help the designer to choose between the different alternatives.

4. An example of application

Suppose you are the manager of a software project whose software design requires a large amount of time to change, and has many productivity maintenance problems.

In a first phase of the project of refactoring design, you detect several problems and several design patterns that can solve them, see Table 2. For this example, the classes are given with a notation in capital letters.





Class A has a heavy daemon; we can apply the Observer pattern.





Class B has a high coupling with the receivers of your messages; we can apply the Chain of Responsibility pattern.





The objects of class C have different kinds of behaviour according to their internal state, with a long switch sentence; we can apply the State pattern.





 Table 2. Example of value of refactoring

We can see in Table 2 that the cost of applying the “chain of responsibility” pattern has a higher value of “introducing a pattern” and indeed this should thus be the first refactoring to do.

5. Issues for the real application: a case of study

VNI S.A. (a pseudonym) is a software factory for several Spanish institutions. The company is specialized in the development, implantation, and maintenance of an integrated package of management software solutions. Since 2006, we are helping to VNI in an integral quality improvement process, which included improving several software applications.

UCO (a pseudonym) is one of several principal products of VNI. Its purpose is to simplify the management of the research activity and to provide information to researches communities. In summary, the UCO project has been developed under J2EE paradigm, using active pages (JSP) as presentation layer, Java for the business layer and Oracle 9i for the database.

The board in charge of the UCO was worried about its maintainability. They had detected an important increase of software maintenance costs. The main problem identified by software engineers was the increases of time for modify the software classes. Many conditions related with domain of application were codified according with rigid sentences, such as complex nested “if” statement or “switch” sentences.

The first proposal was planning a refactoring project to substitute the complex conditional sentences by state patterns [6]. The objective was to substitute every complex conditional sentence. However, soon the team was aware of the cost of this project and planned to substitute 20 complex conditional sentences by month until to substitute the 80% of it in a year.

According to the previous issues, we proposed a value-based software engineering approach for the incorporation of design patterns and for planning the refactoring.

The first step was quantifying the situation. UCO had 153.535 classes and over 4 millions of lines of code (LOC). A cyclomatic complexity (CC) study showed the number of classes that was several problems of maintenance according to complex conditional sentences. The state pattern is, among other, applied when there are “operations have large, multipart conditional statements […] this state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class.” [6]. The CC metric is a good element to see the complex conditional logic (see Table 3).

Ciclomatic Complexity Number of classes Percentage



97,574 %



1,555 %

25- 50


0,595 %



0,134 %



0,067 %



0,075 %

Table 3. Histogram of Cyclomatic Complexity

We focused the main problems on the 0,871 % of the classes, that is, the classes that CC is over 25. The percentage can show minor but it represents 1337 classes. Then we have the possibility of apply the state design pattern in at least 1337 classes.

A way of promising and valuate the refactoring project is the use of the “value of introducing a pattern”. For calculate the value of introducing a pattern we take account the following considerations:


The probability of change for each class was calculated according to file evolutions from the control of versions tool. In this case, the used tool was CVS. With the file evolution (.java), month of evolution and with the “trouble ticket management” tool (in this case a proprietary tool), we could determine the evolutive modifications of every one class and the month of evolution (see Table 4). Therefore, we could know the probability of change of every class [2].

Modifications by Month (last 12 months)

Month 1

Month 2

Month 3

Month 4

Month 5

Month 12

Average of Changes by Month

Class 1








Class 2








Class 3








Class 4








Class 5










Class 1337








Table 4. Probability of Change

COST OF INTRODUCTION (state pattern, by each selected class).

The cost of refactoring the design for introducing a patter was estimated and measured in person-hours. Again, for this calculates we used the CC of every class. Therefore, after study previous and similar works and with the experience of project managers, we set the person-hour estimated according to the CC ranges. The Table 5 shows the estimated values for CC ranges.

Ciclomatic Complexity

Person-hour estimated

25- 50








Table 5. Estimated cost of refactoring

COST OF LOSS IF CHANGE OCCURS (each selected class).

In the same way, from “trouble ticket” tool we can know the cost of change every past evolutive modification. With it, we could calculate the average cost per class and CC range.

Cyclomatic Complexity

Average past cost of change (in monetary units)

25- 50

4 m.u.


10 m.u.


15 m.u.


18 m.u.

Table 6. Estimated cost if change occurs

With the previous dates is easy to calculate the “value of introducing a pattern” in every one class. In this concrete case, we have calculated the value of introducing the state pattern.

An important consideration is that we are taking over “refactoring some classes according to state pattern to avoid the complex conditional sentences and hence improving the maintenance times”. However not always there is a relation one to one among every class and one state pattern. Some classes could need several state patterns. For these reasons, here we can talk over the “value of introducing a set of state patterns”.

6. Conclusions and future work

The motivation behind this article is to propose a value-based approach when introducing patterns in a software design. An important issue behind the proposed method is the rationalization of the use of such patterns. Patterns are a means to an end, not an end in themselves. In addition, we, as software engineers, must know how to measure the exact dose of patterns, which is “healthy” for our designs, and the cost of this dose.

This method is at present being tried out in VNI S.A., a Spanish software factory. In future work, it would be important to develop a more sophisticated method of determining such parameters as cost of introduction, probability, and cost of loss. The case of study presented used one of several methods to calculate it, but another such as calculate it from requirements should be issues to study. In addition, we need to carry out an empirical validation of results as well.

7. References

[1]        B. Boehm, «Value-Based Software Engineering: Overview and Agenda » in Value-Based Software Engineering S. Biffl, A. Aurum, B. Boehm, H. Erdogmus, and P. Grünbacher, Eds.: Springer, 2005, pp. 3-14.

[2]        A. Davis, Great Software Debates: Wiley-IEEE Computer Society Press, 2004.

[3]        W. Harrison, «What Do Software Developers Need to Know about Business?,» IEEE Software, vol. 22, pp. 5-7, 2005.

[4]        J. Garzás and M. Piattini, «An ontology for micro-architectural design knowledge,» IEEE Software Magazine, vol. 22, pp. 28-33, 2005.

[5]        P. Wendorff, «Assessment of Design Patterns during Software Reengineering: Lessons Learned from a Large Commercial Project,» presented at Procedings of the Fifth European Conference on Software Maintenance and Reeingineering (CSMR), Lisbon, Portugal, 2001.

[6]        E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Addison-Wesley Professional, 1995.

[1] A task that runs a certain number of times per unit of time.

[2] The systems this company maintains have an approximate constant number of modifications over the years, because their requirements evolve continuously.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

1 Comment

  1. Socrates una vez dijo:

    sé que no sé…. bonita es la humildad.

    Siempre he pensado en aplicar los patrones de diseño desde un punto de vista estratégico… así para cada estrategia usamos un patrón que se adecue a ello.
    Para aplicar un patrón de diseño más importante que saber el impacto que tiene un cambio, es más importante saber:
    “qué nivel de flexibilidad resta para el cliente en los cambios producidos en un futuro”.

    Es decir ¿Cuánto cuesta cambiar de proveedor a largo plazo? o ¿Cuándo un cliente puede elegir qué servicios quiere restar de su negocio para que siga conservando su valor?


  1. - Información Valora en No hay resumen disponible para esta anotación...

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This