Journal of Computer Science and Technology

, Volume 24, Issue 2, pp 262–272 | Cite as

Do Rules and Patterns Affect Design Maintainability?

  • Javier GarzásEmail author
  • Félix García
  • Mario Piattini
Regular Paper


At the present time, best rules and patterns have reached a zenith in popularity and diffusion, thanks to the software community’s efforts to discover, classify and spread knowledge concerning all types of rules and patterns. Rules and patterns are useful elements, but many features remain to be studied if we wish to apply them in a rational manner. The improvement in quality that rules and patterns can inject into design is a key issue to be analyzed, so a complete body of empirical knowledge dealing with this is therefore necessary. This paper tackles the question of whether design rules and patterns can help to improve the extent to which designs are easy to understand and modify. An empirical study, composed of one experiment and a replica, was conducted with the aim of validating our conjecture. The results suggest that the use of rules and patterns affect the understandability and modifiability of the design, as the diagrams with rules and patterns are more difficult to understand than non-rule/pattern versions and more effort is required to carry out modifications to designs with rules and patterns.


design patterns and rules maintainability software quality object-oriented design 


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. [1]
    Agerbo E, Cornils A. How to preserve the benefits of design patterns. In Proc. Conference on Object Oriented Programming, Systems, Languages, and Applications (OOPSLA’98), Vancouver, Canada, Oct. 18–22, 1998, pp.134–143.Google Scholar
  2. [2]
    Gamma E, Helm R, Johnson R, Vlissides J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1995.Google Scholar
  3. [3]
    Coplien J, Schmidt D. Pattern Languages of Program Design. Addison-Wesley Publishing Company, 1995.Google Scholar
  4. [4]
    Garzás J, Piattini M. An ontology for micro-architectural design knowledge. IEEE Software, 2005, 22(2): 28–33.CrossRefGoogle Scholar
  5. [5]
    Pescio C C. Principles versus patterns. IEEE Computer, 1997, 30(9): 130–131.Google Scholar
  6. [6]
    Wiederhold G. What is your software worth? Communications of the ACM, 2006, 49(9): 65–75.CrossRefGoogle Scholar
  7. [7]
    Glass R L. Facts and Fallacies of Software Engineering. Addison Wesley, 2003.Google Scholar
  8. [8]
    Reibing R. The impact of pattern use on design quality. In Proc. OOPSLA Workshop Beyond Design: Patterns (Mis)used, Tampa Bay, Florida, USA, Oct. 14–18, 2001.Google Scholar
  9. [9]
    Bieman J, Jain D, Yang H. OO design patterns, design structure, and program changes: An industrial case study. In Proc. 17th IEEE International Conference on Software Maintenance (ICSM’01), Florence, Italy, Nov. 6–10, 2001, pp.580–589.Google Scholar
  10. [10]
    Wendorff P. Assessment of design patterns during software reengineering: Lessons learned from a large commercial project. In Proc. the Fifth European Conference on Software Maintenance and Reengineering (CSMR), Lisbon, Portugal, IEEE Computer Society, March 14–16, 2001, pp.77–84.Google Scholar
  11. [11]
    Bezivin J, Jouault F, Touzet D. Principles, standards and tools for model engineering. In Proc. 10th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS’2005), Shanghai, China, June 20, 2005, pp.28–29.Google Scholar
  12. [12]
    Selic B. The pragmatics of model-driven development. IEEE Software, 2003, 20(5): 19–25.CrossRefGoogle Scholar
  13. [13]
    Bieman J, Straw G,Wang H, Munger W, Alexander R. Design patterns and change proneness: An examination of five evolving systems. In Proc. Ninth International Software Metrics Symposium, Sidney, Australia, Sept. 3–5, 2003, pp.40–49.Google Scholar
  14. [14]
    Prechelt L, Unger B, Tichy W F, Brössler P, Votta L G. A controlled experiment in maintenance comparing design patterns to simpler solutions. IEEE Transactions on Software Engineering, December, 2001, 27(12): 1134–1144.CrossRefGoogle Scholar
  15. [15]
    Masuda G, Sakamoto N, Ushijima K. Redesigning of an existing software using design patterns. In Proc. the International Symposium on Principles of Software Evolution (ISPSE’00), Kanazawa, Japan, Nov. 1–2, 2000, pp.165–169.Google Scholar
  16. [16]
    Vokàc M. Defect frequency and design patterns: An empirical study of industrial code. IEEE Transactions on Software Engineering, December 2004, 30(12): 904–917.CrossRefGoogle Scholar
  17. [17]
    Elish M. Do structural design patterns promote design stability? In Proc. the 30th Annual International Computer Software and Applications Conference (COMPSAC’06), Chicago, USA, Sept. 17–21, 2006, pp.215–220.Google Scholar
  18. [18]
    Ng T H, Cheung S C, Chan W K, Yu Y T. Do maintainers utilize deployed design patterns effectively? In Proc. International Conference on Software Engineering (ICSE), Minneapolis, USA, May 19–27, 2007, pp.168–177.Google Scholar
  19. [19]
    Ng T H, Cheung S C, Chan W K, Yu Y T. Work experience versus refactoring to design patterns: A controlled experiment. In Proc. SIGSOFT FSE, Portland, USA, 2006, pp.12–22.Google Scholar
  20. [20]
    Prechelt L, Philippsen M, Tichy W F. Two controlled experiments assessing the usefulness of design pattern documentation in program maintenance. IEEE Transaction of Software Engineering, 2002, 28(6): 595–606.CrossRefGoogle Scholar
  21. [21]
    Ng T H, Cheung S C. Proactive views on concrete aspects: A pattern documentation approach for software evolution. In Proc. 27th Annual International Computer Software and Applications Conference (COMPSAC’03), Dallas, USA, Nov. 3–6, 2003, p.242.Google Scholar
  22. [22]
    Ng T H, Cheung S C. Enhancing class commutability in the deployment of design patterns. Information & Software Technology, 2005, 47(12): 797–804.CrossRefGoogle Scholar
  23. [23]
    Garzàs J, Piattini M (eds.). Object-Oriented Design Knowledge: Principles, Heuristics, Best Practices. Idea Group Inc, 2006.Google Scholar
  24. [24]
    Martin R. Agile Software Development, Principles, Patterns, and Practices. Prentice Hall, 2003.Google Scholar
  25. [25]
    Eysenck M, Keane M. Cognitive Psychology: A Student’s Handbook. Lawrence Erlbaum Associates: Mahwah NJ, 2000, p.540.Google Scholar
  26. [26]
    Genero M, Moody D, Piattini M. Assessing the capability of internal metrics as early indicators of maintenance effort through experimentation. Journal of Software Maintenance and Evolution: Research and Practice, 2005, 17(3): 225–246.CrossRefGoogle Scholar
  27. [27]
    Patig S. A practical guide to testing the understandability of notations. In Proc. Fifth Asia-Pacific Conference on Conceptual Modelling (APCCM 2008), Australia, January 2008, pp.49–55.Google Scholar
  28. [28]
    Dong J. Adding pattern related information in structural and behavioral diagrams. Information and Software Technology, 2004, 46(5): 293–300.CrossRefGoogle Scholar

Copyright information

© Springer 2009

Authors and Affiliations

  • Javier Garzás
    • 1
    Email author
  • Félix García
    • 2
  • Mario Piattini
    • 2
  1. 1.Kybele ConsultingMadridSpain
  2. 2.Alarcos Research Group — Institute of Information Technologies and Systems Department of Information Technologies and Systems — Escuela Superior de Informáica University of Castilla-La ManchaPaseo de la UniversidadCiudad RealSpain

Personalised recommendations