Relating Developers’ Concepts and Artefact Vocabulary in a Financial Software Module

Developers working on unfamiliar systems are challenged to accurately identify where and how high-level concepts are implemented in the source code. Without additional help, concept location can become a tedious, time-consuming and error-prone task. In this paper we study an industrial financial application for which we had access to the user guide, the source code, and some change requests. We compared the relative importance of the domain concepts, as understood by developers, in the user manual and in the source code. We also searched the code for the concepts occurring in change requests, to see if they could point developers to code to be modified. We varied the searches (using exact and stem matching, discarding stop-words, etc.) and present the precision and recall. We discuss the implication of our results for maintenance

Features of post-crisis protectionism in Asia and the Pacific

This paper provides an overview of developments in implementation of protectionist measures relevant for Asia-Pacific economies in the period associated with recovery after the Global Economic Crisis of 2008/2009. At the very start of the Global Economic Crisis, there was a real fear that the sharp collapse in exports and production in many countries would lead to repeat of the damaging trade wars from the 1930s.Post-crisis protentionalism, asia-the pacific, glonal economic crisis

Some issues in the 'archaeology' of software evolution

During a software project's lifetime, the software goes through many changes, as components are added, removed and modified to fix bugs and add new features. This paper is intended as a lightweight introduction to some of the issues arising from an `archaeological' investigation of software evolution. We use our own work to look at some of the challenges faced, techniques used, findings obtained, and lessons learnt when measuring and visualising the historical changes that happen during the evolution of software

An Evaluation of Design Rule Spaces as Risk Containers

It is well understood that software development can be a risky enterprise and industrial projects often overrun budget and schedule. Effective risk management is, therefore, vital for a successful project outcome. Design Rule Spaces (DRSpaces) have been used by other researchers to understand why implemented software is error-prone. This industrial case study evaluates whether such spaces are durable, meaningful, and isolating risk containers. DRSpaces were created from UML class diagrams of architectural design artefacts. In our study, object orientated metrics were calculated from the UML diagrams, and compared to the error-proneness of the DRSpace implementation, to determine whether architectural coupling translated into implementation difficulties. A correlation between architectural coupling and error-proneness of DRSpaces was observed in the case study. Software developers were asked to identify DRSpaces they found difficult to implement, in order to understand which factors, other than architectural coupling, were also important. The qualitative results show agreement between the code areas developers found difficult to implement and the error-prone DRSpaces. However, the results also show that architectural coupling is just one risk factor of many. The case study suggests that architectural DRSpaces can be used to facilitate a targeted risk review prior to implementation and manage risk

A Snapshot of contemporary protectionism: How important are the murkier forms of trade discrimination?

This paper provides a snapshot of current protectionist dynamics making extensive use of the GTA database. Two methods of estimating the trade covered by crisis-era protectionism are also examined.Protectionism, murkier, trade discrimination

A different perspective on canonicity

One of the most interesting aspects of Conceptual Structures Theory is the notion of canonicity. It is also one of the most neglected: Sowa seems to have abandoned it in the new version of the theory, and most of what has been written on canonicity focuses on the generalization hierarchy of conceptual graphs induced by the canonical formation rules. Although there is a common intuition that a graph is canonical if it is "meaningful'', the original theory is somewhat unclear about what that actually means, in particular how canonicity is related to logic. This paper argues that canonicity should be kept a first-class notion of Conceptual Structures Theory, provides a detailed analysis of work done so far, and proposes new definitions of the conformity relation and the canonical formation rules that allow a clear separation between canonicity and truth

Commentary on ‘Software architectures and mobility: A roadmap’

Medvidovic and Edwards provide in their paper (henceforth referred to as the Roadmap) a good survey of the variety of architectural concerns and approaches to mobility. This commentary is intended to complement the Roadmap, discussing additional or alternative concepts, issues and approaches. The ubiquity of mobile computing devices has enabled communication and access to information and services at an unprecedented scale. Novel application domains and technological advances make the boundaries between mobile, ubiquitous, pervasive and autonomic systems fuzzy. To meet user demands, applications are likely to include facets of several types of systems. We therefore start this commentary with a discussion on what mobility means (Section 2) followed by when does mobility impact architecture (Section 3). Finally, we touch upon two crucial aspects of mobile systems that can benefit from a principled architectural approach: autonomy (Section 4) and privacy (Section 5)