Research Proposal: Objective Evaluation of Object Oriented Design Quality Jamie Stevenson University of Strathclyde Computer & Information Sciences Livingstone Tower, G1 1XH 0141-548-3189 (+44) jamie.stevenson@strath.ac.uk ABSTRACT This paper provides an outline of the general area of the author’s PhD and the initial avenues of investigation. This focuses on the notion of design quality and the extent to which we can compare and quantify the quality of software systems, with the ultimate goal of being able to identify exemplars of good design. An initial pilot study examining “program to an interface” use in open source systems has identified that any general notion of quality must be applicable across a wide range of systems and architectures. Categories and Subject Descriptors D.1.5 [Programming Techniques]: Object Oriented Programming, D.2.2 [Software Engineering]: Design Tools and Techniques --- object-oriented design method, D.2.9 [Management]: Software quality assurance (SQA), D.3.3 [Program Languages]: Language Constructs and Features --- Java interface General Terms Design, Standardization. Keywords design quality, non-functional requirements, programming guidelines. 1. INTRODUCTION Many metrics are negative models in the sense that their primary goal is to avoid identifiable types of design pitfall - good design is defined in terms of a lack of detectable flaws. These approaches are useful for meeting functional requirements, however, general metric thresholds may not identify all instances of poor design. This research is motivated by the notion of a positive empirical model of good design in object oriented software - primarily concerned with motivating the programmer towards better designs. The approaches proposed will look at design elements in the context of adjacent code and accepted design guidelines. For the purposes of this study, we assume that the design being examined already meets its functional specification. This project will consider a program as an evolving design document with the programmer as the primary end-user. An initial pilot study has revealed that there is wide variation in program composition and architectural styles, indicating that any empirical definition of quality must be as flexible as the systems it aims to describe. 2. RESEARCH BACKGROUND Software engineering emerged to deal with complexity – early approaches were borrowed from other engineering disciplines and lead to the adoption of static interpretations of processes such as waterfall and V-model development [1]. These practices assumed that software could be designed in a formal process which produces a design, which would specify the required code, the logical end- goal being model-driven development. This approach has fallen out of use in favour of agile processes where code is generated early and often – this prototype-test-modify approach is more akin to the design process in other engineering disciplines. The act of programming is arguably more similar to design activity than a construction activity in the sense that it involves iterative refinement of ideas [2]. The actual building process for software is done by the compiler once the program (the design) is complete, the final product being the compiled, runnable program. Due to the low cost of this build stage in most cases it is easier to compile and run software to check a design (program) works than to scrutinize the design further. We see this trend emerging in the hardware industry as rapid prototyping via 3D printing becomes cheaper. Empirical research in software engineering is increasingly popular as it produces clearly analysable results compared to vague discussions on what design really means – motivated by a search for objective, robust indicators of quality and more universally applicable models of quality. This is in contrast with the software industry where applications are seen more as a mechanism with a specified functionality. Historically, non-functional requirements, have taken a secondary role to functional development of a product, these are increasingly seen as important – particularly in relation to reliability and security. This may be in part due to the misconception that the customer/client is the primary beneficiary of the source code. In this paper it is argued that this is not the case – the primary users of source code are the development and maintenance programmers. The end user in most cases is completely unaware of the qualities of source code, other than the function of the software it describes. 3. MOTIVATION FOR RESEARCH When examining code for quality, there are three main concerns, listed in what is considered to be the most commonly perceived order of priority. 3.1 Functional Requirements Does the program constructed from the design meet the specification? This is usually confirmed though various forms of unit testing and user-acceptance testing. Source-code facing tests Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. EASE Doctoral Symposium ’14, May 13–14, 2014, London, UK. Copyright 2014 ACM 1-58113-000-0/00/0010 …$15.00.