ABSTRACT
When a software design decision has a negative impact on one or more quality attributes, we call it a design problem. For example, the Fat Interface problem indicates that an interface exposes non-cohesive services Thus, clients and implementations of this interface may have to handle with services that they are not interested. A design problem such as this hampers the extensibility and maintainability of a software system. As illustrated by the example, a single design problem often affects several elements in the program. Despite its harmfulness, it is difficult to identify a design problem in a system. It is even more challenging to identify design problems when the source code is the only available artifact. In particular, no study has observed what strategy(ies) developers use in practice to identify design problems when the design documentation is unavailable. In order to address this gap, we conducted a qualitative analysis on how developers identify design problems in two different scenarios: when they are either familiar (Scenario 1) or unfamiliar (Scenario 2) with the analyzed systems. Developers familiar with the systems applied a diverse set of strategies during the identification of each design problem. Some strategies were frequently used to locate code elements for analysis, and other strategies were frequently used to confirm design problems in these elements. Developers unfamiliar with the systems relied only on the use of code smells along the task. Despite some differences among the subjects from both scenarios, we noticed that developers often search for multiple indicators during the identification of each design problem.
- Holger Bär and Oliver Ciupke. 1998. Exploiting Design Heuristics for Automatic Problem Detection. In Workshop Ion on Object-Oriented Technology (ECOOP '98). Springer-Verlag, London, UK, UK, 73--74. Google ScholarDigital Library
- João Brunet, Gail C. Murphy, Ricardo Terra, Jorge Figueiredo, and Dalton Serey. 2014. Do Developers Discuss Design?. In Proceedings of the 11th Working Conference on Mining Software Repositories (MSR 2014). New York, NY, USA, 340--343. Google ScholarDigital Library
- Stephen Cass. 2016. The 2016 Top Programming Language. (July 2016). http://spectrum.ieee.org/computing/software/the-2016-top-programming-languagesGoogle Scholar
- Xi Chen, Abhijit Davare, Harry Hsieh, Alberto Sangiovanni-Vincentelli, and Yosinori Watanabe. 2005. Simulation Based Deadlock Analysis for System Level Designs. In Proceedings of the 42Nd Annual Design Automation Conference (DAC '05). ACM, New York, NY, USA, 260--265. Google ScholarDigital Library
- O. Ciupke. 1999. Automatic detection of design problems in object-oriented reengineering. In Proceedings of Technology of Object-Oriented Languages and Systems - TOOLS 30 (Cat. No.PR00278). 18--32. Google ScholarCross Ref
- M Fowler. 1999. Refactoring: Improving the Design of Existing Code. Addison-Wesley Professional, Boston. Google ScholarDigital Library
- Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. 1995. Design Patterns: Elements of Reusable Object-oriented Software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. Google ScholarDigital Library
- J Garcia, I Ivkovic, and N Medvidovic. 2013. A Comparative Analysis of Software Architecture Recovery Techniques. In Proceedings of the 28th IEEE/ACM International Conference on Automated Software Engineering; Palo Alto, USA. Google ScholarDigital Library
- J Garcia, D Popescu, G Edwards, and N Medvidovic. 2009. Identifying Architectural Bad Smells. In CSMR09; Kaiserslautern, Germany. IEEE. Google ScholarDigital Library
- M Godfrey and E Lee. 2000. Secrets from the Monster: Extracting Mozilla's Software Architecture. In CoSET-00; Limerick, Ireland. 15--23.Google Scholar
- P. Kaminski. 2007. Reforming Software Design Documentation. In 14th Working Conference on Reverse Engineering (WCRE 2007). 277--280. Google ScholarDigital Library
- Craig Larman. 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition). Prentice Hall PTR, Upper Saddle River, NJ, USA. Google ScholarDigital Library
- A MacCormack, J Rusnak, and C Baldwin. 2006. Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code. Manage. Sci 52, 7 (2006), 1015--1030. Google ScholarDigital Library
- I. Macia, R. Arcoverde, E. Cirilo, A. Garcia, and A. von Staa. 2012. Supporting the identification of architecturally-relevant code anomalies. In ICSM12. 662--665. Google ScholarDigital Library
- I. Macia, R. Arcoverde, A. Garcia, C. Chavez, and A. von Staa. 2012. On the Relevance of Code Anomalies for Identifying Architecture Degradation Symptoms. In CSMR12. 277--286. Google ScholarDigital Library
- Isela Macia, Joshua Garcia, Daniel Popescu, Alessandro Garcia, Nenad Medvidovic, and Arndt von Staa. 2012. Are Automatically-detected Code Anomalies Relevant to Architectural Modularity?: An Exploratory Analysis of Evolving Systems. In AOSD '12. ACM, New York, NY, USA, 167--178. Google ScholarDigital Library
- Robert C. Martin and Micah Martin. 2006. Agile Principles, Patterns, and Practices in C# (Robert C. Martin). Prentice Hall PTR, Upper Saddle River, NJ, USA. Google ScholarDigital Library
- Complementar Material. 2017. https://ssousaleo.github.io/SBES2017/. (2017).Google Scholar
- Ran Mo, Yuanfang Cai, R. Kazman, and Lu Xiao. 2015. Hotspot Patterns: The Formal Definition and Automatic Detection of Architecture Smells. In Software Architecture (WICSA), 2015 12th Working IEEE/IFIP Conference on. 51--60. Google ScholarDigital Library
- N Moha, Y Gueheneuc, L Duchien, and A Le Meur. 2010. DECOR: A Method for the Specification and Detection of Code and Design Smells. IEEE Transaction on Software Engineering 36 (2010), 20--36. Google ScholarDigital Library
- W Oizumi, A Garcia, L Sousa, B Cafeo, and Y Zhao. 2016. Code Anomalies Flock Together: Exploring Code Anomaly Agglomerations for Locating Design Problems. In The 38th International Conference on Software Engineering; USA. Google ScholarDigital Library
- David L. Parnas. 1978. Designing Software for Ease of Extension and Contraction. In Proceedings of the 3rd International Conference on Software Engineering (ICSE '78). IEEE Press, Piscataway, NJ, USA, 264--277. Google ScholarDigital Library
- Per Runeson, Martin Host, Austen Rainer, and Bjorn Regnell. 2012. Case Study Research in Software Engineering: Guidelines and Examples. Wiley Publishing. Google ScholarDigital Library
- S Schach, B Jin, D Wright, G Heller, and A Offutt. 2002. Maintainability of the Linux kernel. Software, IEE Proceedings--149, 1 (2002), 18--23.Google ScholarCross Ref
- Marcelino Campos Oliveira Silva, Marco Tulio Valente, and Ricardo Terra. 2016. Does Technical Debt Lead to the Rejection of Pull Requests?. In Proceedings of the 12th Brazilian Symposium on Information Systems (SBSI '16). 248--254. Google ScholarDigital Library
- TIOBE software. 2017. The Java Programming Language. (April 2017). https://www.tiobe.com/tiobe-index/java/Google Scholar
- A. Strauss and J.M. Corbin. 1998. Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory. SAGE Publications.Google Scholar
- Antony Tang, Aldeida Aleti, Janet Burge, and Hans van Vliet. 2010. What makes software design effective? Design Studies 31, 6 (2010), 614--640. Special Issue Studying Professional Software Design.Google ScholarCross Ref
- A. Trifu and R. Marinescu. 2005. Diagnosing design problems in object oriented systems. In WCRE'05. 10 pp. Google ScholarDigital Library
- Adrian Trifu and Urs Reupke. 2007. Towards Automated Restructuring of Object Oriented Systems. In CSMR '07 IEEE, Washington, DC, USA, 39--48. Google ScholarDigital Library
- Twitter. 2017. Working at Twitter. (April 2017). Available at https://about.twitter.com/careers.Google Scholar
- J van Gurp and J Bosch. 2002. Design erosion: problems and causes. Journal of Systems and Software 61, 2(2002), 105-- 119. Google ScholarDigital Library
- S. Vidal, E. Guimaraes, W. Oizumi, A. Garcia, A. D. Pace, and C. Marcos. 2016. Identifying Architectural Problems through Prioritization of Code Smells. In SBCARS16. 41--50.Google Scholar
- Lu Xiao, Yuanfang Cai, Rick Kazman, Ran Mo, and Qiong Feng. 2016. Identifying and Quantifying Architectural Debt. In Proceedings of the 38th International Conference on Software Engineering (ICSE '16). ACM, New York, NY, USA, 488--498. Google ScholarDigital Library
- Yahoo! 2017. Explore Career Opportunities. (April 2017). Available at https://careers.yahoo.com/us/buildyourcareer.Google Scholar
- A Yamashita and L Moonen. 2012. Do code smells reflect important maintainability aspects?. In ICSM12. 306--315. Google ScholarDigital Library
Index Terms
- How Do Software Developers Identify Design Problems?: A Qualitative Analysis
Recommendations
Identifying design problems in the source code: a grounded theory
ICSE '18: Proceedings of the 40th International Conference on Software EngineeringThe prevalence of design problems may cause re-engineering or even discontinuation of the system. Due to missing, informal or outdated design documentation, developers often have to rely on the source code to identify design problems. Therefore, ...
Revealing design problems in stinky code: a mixed-method study
SBCARS '17: Proceedings of the 11th Brazilian Symposium on Software Components, Architectures, and ReuseDevelopers often have to locate design problems in the source code. Several types of design problem may manifest as code smells in the program. A code smell is a source code structure that may reveal a partial hint about the manifestation of a design ...
A survey of software design techniques
Software design is the process which translates the requirements into a detailed design representation of a software system. Good software design is a key to produce reliable and understandable software. To support software design, many techniques and ...
Comments