This research investigates the evolution of object-oriented inheritance hierarchies in open source, Java systems. The paper contributes an understanding of how hierarchies, particularly large complex hierarchies, evolve in 'real world' systems. It informs object-oriented design practices that aim to control or avoid these complicated design structures. The study is based on a detailed analysis of 665 inheritance hierarchies drawn from a total of 262 versions of 10 open source systems. The research contributions include that: i) the majority of inheritance hierarchies are 'simple' in structure and remain that way throughout their lifetimes ii) the majority of hierarchies are stable in terms of size and shape throughout their lifetimes iii) there is a minority of large, complex, branching 'Subtree' hierarchies that continue to grow ever more complicated as the systems evolve iv) a detailed analysis of some of these larger hierarchies finds evidence of 'good' object-oriented design practices being used but also highlights the significant challenges involved in understanding and refactoring these complex structures. There is clear evidence that some of the complex hierarchies are emphasising reuse while others appear focused on type inheritance.

The aim of this research is to use Social Cognitive Career Theory (SCCT) to identify and understand reasons why students choose to study Computer Science (CS) at university. SCCT focuses on students' prior experience, social support, self-efficacy and outcome expectation. The research is partly motivated by the desire to increase female participation rates in CS, particularly in the UK. Policymakers can use the factors that both females and males identify as influencing their choice of studying CS to enhance the experiences of all students prior to coming to university, but female students in particular. The study uses a semi-structured interview with 17 mixed gender subjects currently studying CS at three Scottish universities. The findings are that social support from family, teachers, friends and mentors is a particularly important factor in choosing to study CS, especially for female subjects. The career paths offered by a CS degree is another major factor, not just the potential jobs, but also the general value of a CS education and the potential to make useful contributions to society. School education appeared to have limited influence, though exposure to problem solving, programming, online self-learning and internships are positive influences. The stereotypical view of CS students as 'geeks' is outdated and unhelpful - it is more appropriate to see them as 'analytical' or 'over-achievers'. Subjects make many suggestions for improving the CS education provided at school, especially to make it more attractive to females, including: make it compulsory, teach it earlier, include more programming and problem solving, and increase the visibility of female exemplars and role models.

This research investigates how object-oriented inheritance is actually used in practice. The aim is to close the gap between inheritance guidance and inheritance practice. It is based on detailed analyses of 2440 inheritance hierarchies drawn from 14 open-source systems. The original contributions made by this paper concern pragmatic assessment of inheritance hierarchy design quality. The findings show that inheritance is very widely used but that most of the usage patterns that occur in practice are simple in structure. They are so simple that they may not require much inheritance-specific design consideration. On the other hand, the majority of classes defined using inheritance actually appear within a relatively small number of large, complex hierarchies. While some of these large hierarchies appear to have a consistent structure, often based on a problem domain model or a design pattern, others do not. Another contribution is that the quality of hierarchies, especially the large problematic ones, may be assessed in practice based on size, shape, and the definition and invocation of novel methods - all properties that can be detected automatically.

Design quality is vital if software is to be maintainable. What practices do developers actually use to achieve design quality in their day-to-day work and which of these do they find most useful? To discover the extent to which practitioners concern themselves with object-oriented design quality and the approaches used when determining quality in practice, a questionnaire survey of 102 software practitioners, approximately half from the UK and the remainder from elsewhere around the world was used. Individual and peer experience are major contributors to design quality. Classic design guidelines, well-known lower level practices, tools and metrics all can also contribute positively to design quality. There is a potential relationship between testing practices and design quality. Inexperience, time pressures, novel problems, novel technology, and imprecise or changing requirements may have a negative impact on quality. Respondents with most experience are more confident in their design decisions, place more value on reviews by team leads and are more likely to rate design quality as very important. For practitioners, these results identify the techniques and tools that other practitioners find effective. For researchers, the results highlight a need for more work investigating the role of experience in the design process and the contribution experience makes to quality. There is also the potential for more in-depth studies of how practitioners are actually using design guidance, including Clean Code. Lastly, the potential relationship between testing practices and design quality merits further investigation.

SUMMARY Identifying bug origins – the point where erroneous code was introduced – is crucial for many software engineering activities, from identifying process weaknesses to gathering data to support bug detection tools. Unfortunately, this information is not usually recorded when fixing bugs, and recovering it later is challenging. Recently, the text approach and the dependence approach have been developed to tackle this problem. Respectively, they examine textual and dependence‐related changes that occurred prior to a bug fix. However, only limited evaluation has been carried out, partially because of a lack of available implementations and of datasets linking bugs to origins. To address this, origins of 174 bugs in three projects were manually identified and compared to a simulation of the approaches. Both approaches were partially successful across a variety of bugs – achieving 29–79% precision and 40–70% recall. Results suggested the precise definition of program dependence could affect performance, as could whether the approaches identified a single or multiple origins. Some potential improvements are explored in detail and identify pragmatic strategies for combining techniques along with simple modifications. Even after adopting these improvements, there remain many challenges: large commits, unrelated changes and long periods between origins and fixes all reduce effectiveness. Copyright © 2013 John Wiley & Sons, Ltd.

Abstract Software development projects are inherently cooperative, requiring many developers to coordinate their efforts to produce complex systems. An integral part of this process is the development and maintenance of a shared understanding concerning the state of software project tasks, artefacts, and the activities and expertise of developers working on the project. In co‐located settings, this vitalawareness informationthat concerns developers, either directly or tangentially, is typically acquired using formal, regular meetings, informal personal interruptions and electronic communication. Developing and maintaining such an awareness are far more difficult in distributed teams where developers are separated by time and space. The goal of this review is to help bridge the gap between the theoretical benefits of distributed collaborative software development and the practical impediments to successful implementation, and more specifically, achieving similar levels of awareness in distributed settings to those available in co‐located settings. The review starts with a detailed discussion of awareness and awareness types with particular relevance to collaboration. This is followed by a discussion of how awareness information is disseminated during collaborative processes. Awareness information needs and dissemination mechanisms in software development teams are then presented. The main contribution of the review, derived from a comparison of awareness needs in distributed collaborative software engineering and current support from tools and techniques, is that more support is required for the type of awareness known ascontext awareness. Context awareness crosscuts other (more basic) forms of awareness and arises because, over time, individual collaborators work on different sets of tasks and artefacts and form different perceptions of their colleagues; their colleagues' work, roles, and relationships; and, the workspace. This awareness is highlycontextualand therefore cannot be generalized across individuals, entities or activities that are found in a collaboration space. Copyright © 2010 John Wiley & Sons, Ltd.

Recent research has found that many novice programmers often hold non-viable mental models of basic programming concepts which can limit their potential to develop appropriate programming skills. Previous work by the authors suggests that a teaching model that integrates cognitive conflict and program visualisation can help novices formulate appropriate mental models. This paper first outlines a 'concepts roadmap' that provides an ordered approach to learning programming concepts allowing students to build on fundamental base knowledge. It then reports the results of a series of studies investigating the use of the Jeliot visualisation tool as the visualisation component of the proposed learning model when applied to these concepts. The findings include: the ease with which Jeliot can be tailored to visualise a range of concepts using a variety of examples; the Jeliot visualisation of object reference was too complex for CS1 students; further evidence that CS1 students struggle to develop appropriate understanding of a range of key programming concepts; and, further evidence that an integrated cognitive conflict/visualisation strategy can help students develop an appropriate understanding of key programming concepts.

Requirements traceability is a challenge for modern software projects where task dependencies and technical expertise are spread across system developers, abstract model representations such as use cases, and a myriad of code artefacts. This paper presents an approach that monitors the navigation trails left by developers when building code artefacts to realise project use cases. These trails are analysed to generate a relevance ranking of entities that constitute a traceability link between uses cases and code artefacts and the developers responsible for them. Investigation in a software development scenario shows that a range of use case traceability questions can be answered through visualisations which present ordered relevance lists of the entities associated with use cases and by the use of trace graphs where the size of nodes show the importance, or 'information centrality', of system entities.

Software development is a global activity unconstrained by the bounds of time and space. A major effect of this increasing scale and distribution is that the shared understanding that developers previously acquired by formal and informal face-to-face meetings is difficult to obtain. This paper proposes a shared awareness model that uses information gathered automatically from developer IDE interactions to make explicit orderings of tasks, artefacts and developers that are relevant to particular work contexts in collaborative, and potentially distributed, software development projects. The research findings suggest that such a model can be used to: identify entities (developers, tasks, artefacts) most associated with a particular work context in a software development project; identify relevance relationships amongst tasks, developers and artefacts e.g. which developers and artefacts are currently most relevant to a task or which developers have contributed to a task over time; and, can be used to identify potential bottlenecks in a project through a ‘social graph’ view. Furthermore, this awareness information is captured and provided as developers work in different locations and at different times.

Recent research has found that many novice programmers often hold non-viable mental models of basic programming concepts such as assignment and object reference, which can limit their potential to develop programming skills. This paper proposes a constructivist-based teaching model that integrates cognitive conflict and program visualisation with the aim of supporting novice programmers in the formulation of appropriate mental models. The results of an initial empirical study produced three findings of note. Firstly, a teaching model based on either visualisation alone or cognitive conflict integrated with visualisation can help students develop viable models of value assignment. Secondly, there was evidence to suggest that cognitive conflict integrated with visualisation outperformed visualisation alone in helping students develop viable models of the more challenging concept of object reference assignment. And thirdly, there was evidence of an improvement in students' understanding of value and object reference assignment using the teaching model based on visualisation and cognitive conflict.

It is not unusual for a software development organization to expend 40% of total project effort on testing, which call be a very laborious and time-consuming process. Therefore, there is a big necessity for test automation. This paper describes an approach to automatically generate test-data for 00 software exploiting a Genetic Algorithm (GA) to achieve high levels of data-flow (d-u) coverage. A proof-of-concept tool is presented. The experimental results from testing six Java classes helped us identify three categories of problematic test targets, and suggest that in the future full d-u coverage with a reasonable computational cost may be possible if we overcome these obstacles.

Today's large software projects are often characterised by distributed environments with numerous developers separated in space and/or time. This separation means that the common understanding and tacit knowledge that is a feature of closely co-located project teams is very hard to come by. As a consequence, relatively simple tasks such as identifying functionally related modules or finding individuals who are experts in aspects of the system become more challenging and time-consuming. This paper presents a continuum of relevance index (CRI) model that uses information gathered from developer IDE interactions to generate orderings of relevant tasks, project artefacts and developers. A case study is used to demonstrate how the model can be used to attain a shared knowledge and common understanding of the extent to which tasks, artefacts and developers are relevant in a group development work context.

Identifying and isolating the source code associated with a particular feature is a problem that frequently arises in many maintenance tasks. The delocalised nature of object-oriented systems, where the code associated with a feature is distributed across many interrelated objects, makes this problem particularly challenging. This paper presents an approach that combines 'landmark' methods that have a key role in the execution of a particular feature with slicing to create a call graph of related code. The size of this call graph is constrained by the identification of 'barrier' methods which exclude parts of the graph that are not of interest. The approach is supported by a tool, and the evaluation on three open-source systems yields encouraging results and demonstrates the practical applicability of the technique.

This paper describes an investigation into the viability of mental models used by novice programmers at the end of a first year Java programming course. The qualitative findings identify the range of mental models of value and reference assignment held by the participants. The quantitative analysis reveals that approximately one third of students held non-viable mental models of value assignment and only 17% of students held a viable mental model of reference assignment. Further, in terms of a comparison between the participants' mental models and their performance in in-course assessments and final examination, it was found that students with viable mental models performed significantly better than those with non-viable models. These findings are used to propose a more "constructivist" approach to teaching programming based on the integration of "cognitive conflict" and program visualisation.

We describe the development and evaluation of a rigorous approach aimed at the effective and efficient inspection of object-oriented (OO) code. Since the time that inspections were developed they have been shown to be powerful defect detection strategies. However, little research has been done to investigate their application to OO systems, which have very different structural and execution models compared to procedural systems. This suggests that inspection techniques may not be currently being deployed to their best effect in the context of large-scale OO systems. Work to date has revealed three significant issues that need to be addressed - the identification of chunks of code to be inspected, the order in which the code is read, and the resolution of frequent nonlocal references. Three techniques are developed with the aim of addressing these issues: one based on a checklist, one focused on constructing abstract specifications, and the last centered on the route that a use case takes through a system. The three approaches are evaluated empirically and, in this instance, it is suggested that the checklist is the most effective approach, but that the other techniques also have potential strengths. For the best results in a practical situation, a combination of techniques is recommended, one of which should focus specifically on the characteristics of OO.

Frameworks are an attractive form of reuse due to their paradigmatic simplicity. Unfortunately their size and complexity makes understanding how to use them difficult. In addition documentation to support framework reuse often lacks experimental validation and there is little understanding of what artefacts must be documented to increase the effectiveness of documentation techniques. This report describes an empirical investigation into framework reuse. Its aim is to identify the major problems of reuse and the impact of current documentation techniques on these problems. A qualitative approach is employed and developer experiences are captured from three separate reuse studies using multiple forms of data capture. Four major reuse problems are identified by this report. Understanding the functionality of components; the interactions between components; the mapping from the problem domain to the framework implementation and understanding the architectural assumptions in the framework design. The effectiveness of current forms of documentation is evaluated using these problem categories and, as a result, a number of suggestions for improving developer support during reuse are made.

This paper describes the development and experimental evaluation of a rigorous approach for effective object-oriented (OO) code inspection. Since their development, inspections have been shown to be powerful defect detection strategies but little research has been done to investigate their application to OO systems, which have very different structural and execution models compared to procedural systems. Previous investigations have demonstrated that the delocalised nature of OO software - the resolution of frequent non-local references, and the incongruous relationship between its static and dynamic representations, are primary inhibitors to its effective inspection. The experiment investigates a set of three complementary code reading techniques devised specifically to address these problems: one based on a checklist adapted to address the identified problems of OO inspections, one focused on the systematic construction of abstract specifications, and the last centered on the dynamic slice that a use-case takes through a system. The analysis shows that there is a significant difference in the number of defects found between the three reading techniques. The checklist-based technique emerges as the most effective approach but the other techniques also have noticeable strengths and so for the best results in a practical situation a combination of techniques is recommended.

Software inspection is now widely accepted as an effective technique for defect detection. This acceptance is largely based on studies using procedural program code. This paper presents empirical evidence that raises significant questions about the application of inspection to object-oriented code.

The benefits of the object-oriented paradigm are widely cited. At the same time, inspection is deemed to be the most cost-effective means of detecting defects in software products. Why then, is there no published experience, let alone quantitative data, on the application of inspection to object-oriented systems? This paper describes the facilities of the object-oriented paradigm and the issues that these raise when inspecting object-oriented code. Several problems are caused by the disparity between the static code structure and its dynamic runtime behaviour. The large number of small methods in object-oriented systems can also cause problems. This is followed by a description of three areas which may help mitigate problems found. Firstly, the use of various programming techniques may assist in making object-oriented code easier to inspect. Secondly, improved program documentation can help the inspector understand the code under inspection. Finally, tool support can help the inspector analyse the dynamic behaviour of the code. In conclusion, while both the object-oriented paradigm and inspection provide excellent benefits on their own, combining the two may be a difficult exercise, requiring extensive support if it is to be successful.

The object-oriented paradigm is becoming increasingly popular as a result of expert opinion and anecdotal evidence and not on the basis of sound empirical data. The questionnaire survey was undertaken as part of a programme of research to validate unsupported claims about the paradigm. The questionnaire follows structured interviews of experienced object-oriented developers with the intention of confirming the findings on a wider practitioner group. It was posted to relevant electronic newsgroups and to members of an object-oriented (postal) mailing list. The survey received 167 responses to the electronic questionnaire and 119 responses (30% response rate) to the postal version. Results show that respondents are of the view that: (i) the object-oriented paradigm has advantages over other paradigms in terms of ease of analysis and design, programmer productivity, software reuse, and ease of maintenance; (ii) inheritance can introduce difficulties when trying to understand object-oriented software; (iii) missing design documentation and poor or inappropriate design are prevalent problems; (iv) maintenance causes degradation of object-oriented software, but less frequently than conventional software; (v) C++ has many deficiencies in comparison to other purer object-oriented languages.

The empirical study was undertaken as part of a programme of research to explore unsupported claims about the object-oriented paradigm: a series of experiments tested the effect of inheritance on the maintainability of object-oriented software. Subjects were asked to modify object-oriented software with a hierarchy of 3 levels of inheritance depth and equivalent object-based software with no inheritance. The collected timing data showed that subjects maintaining object-oriented software using inheritance performed the modification tasks, on average, approximately 20% quicker than those maintaining equivalent object-based software with no inheritance. An initial inductive analysis revealed that 2 out of 3 subjects performed faster when maintaining the object-oriented software with inheritance. The findings are sufficiently important that attempts to verify the results should be made by independent researchers. Subsequent studies should seek to scale up the findings to the maintenance of more complex software by professional programmers.

This paper investigates the application of object-oriented construction to fault tolerant systems. The resulting system provides traditional fault tolerance within objects, but also a new form of fault tolerance between objects: object diversity. Object diversity extends current practice by integrating diversity in two directions: data and algorithm. This resulting form will allow increased diversity to be incorporated within fault tolerant systems. Further benefits are derived from the use of the inheritance hierarchy as a natural source of redundant components. As class libraries (both general and application specific) grow, more and more "free" redundant components will become available, yielding increasing savings on production costs.>

Empirical studies carried out to help understand the problems of software maintenance are widely held to be of value. A view perhaps less widely recognised within the software engineering domain is that experiments should be replicated both internally and externally to validate the results and build up a cohesive body of knowledge. This paper presents the external replication findings of an experiment which tested the benefits to maintenance of using modular code against nonmodular (monolithic) code. The results of our replication were strikingly different from those of the original which showed that a modular program could be maintained significantly faster than an equivalent monolithic version. An inductive analysis, undertaken to investigate the reasons for this, uncovered evidence of an ability effect and the suggestion that the experiment may have been too artificial.>