<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
   xmlns="http://purl.org/rss/1.0/"
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/"
   xmlns:dcterms="http://purl.org/dc/terms/"

>
<channel rdf:about="http://www.citeulike.org/about">
<pubDate>Thu, 21 Aug 2008 14:18:35 BST</pubDate>


	<title>CiteULike: swiftwatch's library [154 articles]</title>
	<description>CiteULike: swiftwatch's library [154 articles]</description>


	<link>http://www.citeulike.org/user/swiftwatch</link>
	<dc:publisher>CiteULike.org</dc:publisher>
	<dc:language>en-gb</dc:language>
	<dc:rights>Copyright &#169; 2004-2008 citeulike.org</dc:rights>
	<items>
    <rdf:Seq>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2925256"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2712604"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2885400"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2057824"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2818401"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1191882"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1281500"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/712835"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1281491"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2450177"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2450162"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2450155"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2446040"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2439879"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2439803"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2428610"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2428601"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2424082"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2424063"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2396935"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2390087"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2332956"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2235025"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/984431"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2233693"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2227781"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2227773"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/2190660"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/690278"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905019"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905018"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905017"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905016"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905015"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905014"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905013"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905012"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905011"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905008"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905007"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905006"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905005"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905004"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905003"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905002"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905001"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1905000"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1904999"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1904998"/>
        <rdf:li rdf:resource="http://www.citeulike.org/user/swiftwatch/article/1904997"/>

	</rdf:Seq>
	</items>
	</channel>


<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2925256">
    <title>Design Measurement: Some Lessons Learned</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2925256</link>
    <description>&lt;i&gt;IEEE Softw., Vol. 7, No. 2. (March 1990), pp. 17-25.&lt;/i&gt;</description>
    <dc:title>Design Measurement: Some Lessons Learned</dc:title>

    <dc:creator>Dieter Rombach</dc:creator>
    <dc:source>IEEE Softw., Vol. 7, No. 2. (March 1990), pp. 17-25.</dc:source>
    <dc:date>2008-06-25T06:50:54-00:00</dc:date>
    <prism:publicationYear>1990</prism:publicationYear>
    <prism:publicationName>IEEE Softw.</prism:publicationName>
    <prism:issn>0740-7459</prism:issn>
    <prism:volume>7</prism:volume>
    <prism:number>2</prism:number>
    <prism:startingPage>17</prism:startingPage>
    <prism:endingPage>25</prism:endingPage>
    <prism:publisher>IEEE Computer Society Press</prism:publisher>
    <prism:category>design</prism:category>
    <prism:category>lessons</prism:category>
    <prism:category>measurement</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2712604">
    <title>On Weyuker's axioms for software complexity measures</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2712604</link>
    <description>&lt;i&gt;Software Engineering, IEEE Transactions on, Vol. 17, No. 6. (1991), pp. 636-638.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Properties for software complexity measures are discussed. It is shown that a collection of nine properties suggested by E.J. Weyuker is inadequate for determining the quality of a software complexity measure. (see ibid., vol.14, p.1357-65, 1988). A complexity measure which satisfies all nine of the properties, but which has absolutely no practical utility in measuring the complexity of a program is presented. It is concluded that satisfying all of the nine properties is a necessary, but not sufficient, condition for a good complexity measure</description>
    <dc:title>On Weyuker's axioms for software complexity measures</dc:title>

    <dc:creator>JC Cherniavsky</dc:creator>
    <dc:creator>CH Smith</dc:creator>
    <dc:identifier>doi:10.1109/32.87287</dc:identifier>
    <dc:source>Software Engineering, IEEE Transactions on, Vol. 17, No. 6. (1991), pp. 636-638.</dc:source>
    <dc:date>2008-04-24T10:08:14-00:00</dc:date>
    <prism:publicationYear>1991</prism:publicationYear>
    <prism:publicationName>Software Engineering, IEEE Transactions on</prism:publicationName>
    <prism:volume>17</prism:volume>
    <prism:number>6</prism:number>
    <prism:startingPage>636</prism:startingPage>
    <prism:endingPage>638</prism:endingPage>
    <prism:category>complexity</prism:category>
    <prism:category>measurement</prism:category>
    <prism:category>validation</prism:category>
    <prism:category>weyuker</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2885400">
    <title>On the relationships among three software metrics</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2885400</link>
    <description>&lt;i&gt;(1981), pp. 81-88.&lt;/i&gt;</description>
    <dc:title>On the relationships among three software metrics</dc:title>

    <dc:creator>Sallie Henry</dc:creator>
    <dc:creator>Dennis Kafura</dc:creator>
    <dc:creator>Kathy Harris</dc:creator>
    <dc:identifier>doi:10.1145/800003.807911</dc:identifier>
    <dc:source>(1981), pp. 81-88.</dc:source>
    <dc:date>2008-06-12T06:33:07-00:00</dc:date>
    <prism:publicationYear>1981</prism:publicationYear>
    <prism:startingPage>81</prism:startingPage>
    <prism:endingPage>88</prism:endingPage>
    <prism:publisher>ACM</prism:publisher>
    <prism:category>correlation</prism:category>
    <prism:category>flow</prism:category>
    <prism:category>information</prism:category>
    <prism:category>metrics</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2057824">
    <title>An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2057824</link>
    <description>&lt;i&gt;IEEE Trans. Softw. Eng., Vol. 32, No. 12. (December 2006), pp. 971-987.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Senior Member-Brad A. Myers</description>
    <dc:title>An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks</dc:title>

    <dc:creator>Andrew Ko</dc:creator>
    <dc:creator>Michael Coblenz</dc:creator>
    <dc:creator>Htet Aung</dc:creator>
    <dc:identifier>doi:10.1109/TSE.2006.116</dc:identifier>
    <dc:source>IEEE Trans. Softw. Eng., Vol. 32, No. 12. (December 2006), pp. 971-987.</dc:source>
    <dc:date>2007-12-04T19:19:51-00:00</dc:date>
    <prism:publicationYear>2006</prism:publicationYear>
    <prism:publicationName>IEEE Trans. Softw. Eng.</prism:publicationName>
    <prism:issn>0098-5589</prism:issn>
    <prism:volume>32</prism:volume>
    <prism:number>12</prism:number>
    <prism:startingPage>971</prism:startingPage>
    <prism:endingPage>987</prism:endingPage>
    <prism:publisher>IEEE Press</prism:publisher>
    <prism:category>comprehension</prism:category>
    <prism:category>debugging</prism:category>
    <prism:category>empirical</prism:category>
    <prism:category>experiment</prism:category>
    <prism:category>maintenance</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2818401">
    <title>Debugging reinvented: asking and answering why and why not questions about program behavior</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2818401</link>
    <description>&lt;i&gt;(2008), pp. 301-310.&lt;/i&gt;</description>
    <dc:title>Debugging reinvented: asking and answering why and why not questions about program behavior</dc:title>

    <dc:creator>Andrew Ko</dc:creator>
    <dc:creator>Brad Myers</dc:creator>
    <dc:identifier>doi:10.1145/1368088.1368130</dc:identifier>
    <dc:source>(2008), pp. 301-310.</dc:source>
    <dc:date>2008-05-21T06:54:08-00:00</dc:date>
    <prism:publicationYear>2008</prism:publicationYear>
    <prism:startingPage>301</prism:startingPage>
    <prism:endingPage>310</prism:endingPage>
    <prism:publisher>ACM</prism:publisher>
    <prism:category>analysis</prism:category>
    <prism:category>debugging</prism:category>
    <prism:category>dynamic</prism:category>
    <prism:category>program</prism:category>
    <prism:category>slicing</prism:category>
    <prism:category>static</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1191882">
    <title>Building knowledge through families of experiments</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1191882</link>
    <description>&lt;i&gt;Software Engineering, IEEE Transactions on, Vol. 25, No. 4. (1999), pp. 456-473.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Experimentation in software engineering is necessary but difficult. One reason is that there are a large number of context variables and, so, creating a cohesive understanding of experimental results requires a mechanism for motivating studies and integrating results. It requires a community of researchers that can replicate studies, vary context variables, and build models that represent the common observations about the discipline. The paper discusses the experience of the authors, based upon a collection of experiments, in terms of a framework for organizing sets of related studies. With such a framework, experiments can be viewed as part of common families of studies, rather than being isolated events. Common families of studies can contribute to important and relevant hypotheses that may not be suggested by individual experiments. A framework also facilitates building knowledge in an incremental manner through the replication of experiments within families of studies. To support the framework, the paper discusses the experiences of the authors in carrying out empirical studies, with specific emphasis on persistent problems encountered in experimental design, threats to validity, criteria for evaluation, and execution of experiments in the domain of software engineering</description>
    <dc:title>Building knowledge through families of experiments</dc:title>

    <dc:creator>VR Basili</dc:creator>
    <dc:creator>F Shull</dc:creator>
    <dc:creator>F Lanubile</dc:creator>
    <dc:identifier>doi:10.1109/32.799939</dc:identifier>
    <dc:source>Software Engineering, IEEE Transactions on, Vol. 25, No. 4. (1999), pp. 456-473.</dc:source>
    <dc:date>2007-03-28T16:42:09-00:00</dc:date>
    <prism:publicationYear>1999</prism:publicationYear>
    <prism:publicationName>Software Engineering, IEEE Transactions on</prism:publicationName>
    <prism:volume>25</prism:volume>
    <prism:number>4</prism:number>
    <prism:startingPage>456</prism:startingPage>
    <prism:endingPage>473</prism:endingPage>
    <prism:category>empirical</prism:category>
    <prism:category>experiment</prism:category>
    <prism:category>families</prism:category>
    <prism:category>model</prism:category>
    <prism:category>validation</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1281500">
    <title>How Webmining and Coupling Metrics Improve Early Program Comprehension</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1281500</link>
    <description>&lt;i&gt;Program Comprehension, 2006. ICPC 2006. 14th IEEE International Conference on (2006), pp. 74-78.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;During initial program comprehension, software engineers could benefit from knowing the most need-to-beunderstood classes in the system under study in order to kick-start their software reconnaissance. Previously we have used webmining techniques on runtime trace data to identify these important classes. Here, we reprise this webmining technique and make a thorough comparison of its effectiveness when collecting static information of the software system under study. Apache Ant and Jakarta JMeter, two medium-scale open source Java software systems, serve as case studies. From publicly available developers notes we conclude that the webmining technique in combination with dynamic analysis provides the best results with a level of recall of 90% when comparing with the developers&#146; opinion.</description>
    <dc:title>How Webmining and Coupling Metrics Improve Early Program Comprehension</dc:title>

    <dc:creator>A Zaidman</dc:creator>
    <dc:creator>Bart Du Bois</dc:creator>
    <dc:creator>S Demeyer</dc:creator>
    <dc:identifier>doi:10.1109/ICPC.2006.26</dc:identifier>
    <dc:source>Program Comprehension, 2006. ICPC 2006. 14th IEEE International Conference on (2006), pp. 74-78.</dc:source>
    <dc:date>2007-05-07T06:07:52-00:00</dc:date>
    <prism:publicationYear>2006</prism:publicationYear>
    <prism:publicationName>Program Comprehension, 2006. ICPC 2006. 14th IEEE International Conference on</prism:publicationName>
    <prism:startingPage>74</prism:startingPage>
    <prism:endingPage>78</prism:endingPage>
    <prism:category>comprehension</prism:category>
    <prism:category>coupling</prism:category>
    <prism:category>metrics</prism:category>
    <prism:category>mining</prism:category>
    <prism:category>web</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/712835">
    <title>Predicting fault-proneness using OO metrics. An industrial case study</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/712835</link>
    <description>&lt;i&gt;Software Maintenance and Reengineering, 2002. Proceedings. Sixth European Conference on (2002), pp. 99-107.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Software quality is an important external software attribute that is difficult to measure objectively. In this case study, we empirically validate a set of object-oriented metrics in terms of their usefulness in predicting fault-proneness, an important software quality indicator We use a set of ten software product metrics that relate to the following software attributes: the size of the software, coupling, cohesion, inheritance, and reuse. Eight hypotheses on the correlations of the metrics with fault-proneness are given. These hypotheses are empirically tested in a case study, in which the client side of a large network service management system is studied. The subject system is written in Java and it consists of 123 classes. The validation is carried out using two data analysis techniques: regression analysis and discriminant analysis</description>
    <dc:title>Predicting fault-proneness using OO metrics. An industrial case study</dc:title>

    <dc:creator>Ping Yu</dc:creator>
    <dc:creator>T Systa</dc:creator>
    <dc:creator>H Muller</dc:creator>
    <dc:identifier>doi:10.1109/CSMR.2002.995794</dc:identifier>
    <dc:source>Software Maintenance and Reengineering, 2002. Proceedings. Sixth European Conference on (2002), pp. 99-107.</dc:source>
    <dc:date>2006-06-27T18:43:09-00:00</dc:date>
    <prism:publicationYear>2002</prism:publicationYear>
    <prism:publicationName>Software Maintenance and Reengineering, 2002. Proceedings. Sixth European Conference on</prism:publicationName>
    <prism:startingPage>99</prism:startingPage>
    <prism:endingPage>107</prism:endingPage>
    <prism:category>fault-proneness</prism:category>
    <prism:category>metrics</prism:category>
    <prism:category>object-oriented</prism:category>
    <prism:category>prediction</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1281491">
    <title>What&#146;s in a Name? A Study of Identifiers</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1281491</link>
    <description>&lt;i&gt;Program Comprehension, 2006. ICPC 2006. 14th IEEE International Conference on (2006), pp. 3-12.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Readers of programs have two main sources of domain information: identifier names and comments. When functions are uncommented, as many are, comprehension is almost exclusively dependent on the identifier names. Assuming that writers of programs want to create quality identifiers (e.g., include relevant domain knowledge) how should they go about it? For example, do the initials of a concept name provide enough information to represent the concept? If not, and a longer identifier is needed, is an abbreviation satisfactory or does the concept need to be captured in an identifier that includes full words? Results from a study designed to investigate these questions are reported. The study involved over 100 programmers who were asked to describe twelve different functions. The functions used three different &#34;levels&#34; of identifiers: single letters, abbreviations, and full words. Responses allow the level of comprehension associated with the different levels to be studied. The functions include standard algorithms studied in computer science courses as well as functions extracted from production code. The results show that full word identifiers lead to the best comprehension; however, in many cases, there is no statistical difference between full words and abbreviations.</description>
    <dc:title>What&#146;s in a Name? A Study of Identifiers</dc:title>

    <dc:creator>D Lawrie</dc:creator>
    <dc:creator>C Morrell</dc:creator>
    <dc:creator>H Feild</dc:creator>
    <dc:creator>D Binkley</dc:creator>
    <dc:identifier>doi:10.1109/ICPC.2006.51</dc:identifier>
    <dc:source>Program Comprehension, 2006. ICPC 2006. 14th IEEE International Conference on (2006), pp. 3-12.</dc:source>
    <dc:date>2007-05-07T06:01:11-00:00</dc:date>
    <prism:publicationYear>2006</prism:publicationYear>
    <prism:publicationName>Program Comprehension, 2006. ICPC 2006. 14th IEEE International Conference on</prism:publicationName>
    <prism:startingPage>3</prism:startingPage>
    <prism:endingPage>12</prism:endingPage>
    <prism:category>empirical</prism:category>
    <prism:category>identifiers</prism:category>
    <prism:category>study</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2450177">
    <title>Data Mining Static Code Attributes to Learn Defect Predictors</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2450177</link>
    <description>&lt;i&gt;Software Engineering, IEEE Transactions on, Vol. 33, No. 1. (2007), pp. 2-13.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;The value of using static code attributes to learn defect predictors has been widely debated. Prior work has explored issues like the merits of &#34;McCabes versus Halstead versus lines of code counts&#34; for generating defect predictors. We show here that such debates are irrelevant since how the attributes are used to build predictors is much more important than which particular attributes are used. Also, contrary to prior pessimism, we show that such defect predictors are demonstrably useful and, on the data studied here, yield predictors with a mean probability of detection of 71 percent and mean false alarms rates of 25 percent. These predictors would be useful for prioritizing a resource-bound exploration of code that has yet to be inspected</description>
    <dc:title>Data Mining Static Code Attributes to Learn Defect Predictors</dc:title>

    <dc:creator>T Menzies</dc:creator>
    <dc:creator>J Greenwald</dc:creator>
    <dc:creator>A Frank</dc:creator>
    <dc:identifier>doi:10.1109/TSE.2007.256941</dc:identifier>
    <dc:source>Software Engineering, IEEE Transactions on, Vol. 33, No. 1. (2007), pp. 2-13.</dc:source>
    <dc:date>2008-03-01T06:01:41-00:00</dc:date>
    <prism:publicationYear>2007</prism:publicationYear>
    <prism:publicationName>Software Engineering, IEEE Transactions on</prism:publicationName>
    <prism:volume>33</prism:volume>
    <prism:number>1</prism:number>
    <prism:startingPage>2</prism:startingPage>
    <prism:endingPage>13</prism:endingPage>
    <prism:category>data</prism:category>
    <prism:category>defect</prism:category>
    <prism:category>mccabe</prism:category>
    <prism:category>mining</prism:category>
    <prism:category>prediction</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2450162">
    <title>Static analysis of object references in RMI-based Java software</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2450162</link>
    <description>&lt;i&gt;Software Maintenance, 2005. ICSM'05. Proceedings of the 21st IEEE International Conference on (2005), pp. 101-110.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Distributed applications provide numerous advantages related to software performance, reliability, interoperability, and extensibility. This paper focuses on distributed Java programs built with the help of the remote method invocation (RMI) mechanism. We consider points-to analysis for such applications. Points-to analysis determines the objects pointed to by a reference variable or a reference object field. Such information plays a fundamental role as a prerequisite for many other static analyses. We present the first theoretical definition of points-to analysis for RMI-based Java applications, and an algorithm for implementing a flow- and context-insensitive points-to analysis for such applications. We also discuss the use of points-to information for computing call graph information, for understanding data dependencies due to remote memory locations, and for identifying opportunities for improving the performance of object serialization at remote calls. The work described in this paper solves one key problem for static analysis of RMI programs, and provides a starting point for future work on improving the understanding, testing, verification, and performance of RMI-based software.</description>
    <dc:title>Static analysis of object references in RMI-based Java software</dc:title>

    <dc:creator>M Sharp</dc:creator>
    <dc:creator>A Rountev</dc:creator>
    <dc:identifier>doi:10.1109/ICSM.2005.84</dc:identifier>
    <dc:source>Software Maintenance, 2005. ICSM'05. Proceedings of the 21st IEEE International Conference on (2005), pp. 101-110.</dc:source>
    <dc:date>2008-03-01T05:52:54-00:00</dc:date>
    <prism:publicationYear>2005</prism:publicationYear>
    <prism:publicationName>Software Maintenance, 2005. ICSM'05. Proceedings of the 21st IEEE International Conference on</prism:publicationName>
    <prism:startingPage>101</prism:startingPage>
    <prism:endingPage>110</prism:endingPage>
    <prism:category>analysis</prism:category>
    <prism:category>java</prism:category>
    <prism:category>rmi</prism:category>
    <prism:category>static</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2450155">
    <title>Comprehension strategies in programming</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2450155</link>
    <description>&lt;i&gt;(1987), pp. 100-113.&lt;/i&gt;</description>
    <dc:title>Comprehension strategies in programming</dc:title>

    <dc:creator>Nancy Pennington</dc:creator>
    <dc:source>(1987), pp. 100-113.</dc:source>
    <dc:date>2008-03-01T05:44:50-00:00</dc:date>
    <prism:publicationYear>1987</prism:publicationYear>
    <prism:startingPage>100</prism:startingPage>
    <prism:endingPage>113</prism:endingPage>
    <prism:publisher>Ablex Publishing Corp.</prism:publisher>
    <prism:category>comprehension</prism:category>
    <prism:category>program</prism:category>
    <prism:category>strategies</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2446040">
    <title>Measurement and experimentation in software engineering</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2446040</link>
    <description>&lt;i&gt;Proceedings of the IEEE, Vol. 68, No. 9. (1980), pp. 1144-1157.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;The contributions of measurement and experimentation to the state of the art in software engineering are reviewed. The role of measurement in developing theoretical models is discussed, and concerns for reliability and validity are stressed. Current approaches to measuring software characteristics are presented as examples. In particular, software complexity metrics related to control flow, module interconnectedness, and Halstead's Software Science are discussed. The use of experimental methods in evaluating cause-effect relationships is also discussed. Example programs of experimental research which investigated conditional statements and control flow are reviewed. The conclusion argues that many advances in software engineering will be related to improvements in the measurement and experimental evaluation of software techniques and practices.</description>
    <dc:title>Measurement and experimentation in software engineering</dc:title>

    <dc:creator>B Curtis</dc:creator>
    <dc:source>Proceedings of the IEEE, Vol. 68, No. 9. (1980), pp. 1144-1157.</dc:source>
    <dc:date>2008-02-29T02:04:50-00:00</dc:date>
    <prism:publicationYear>1980</prism:publicationYear>
    <prism:publicationName>Proceedings of the IEEE</prism:publicationName>
    <prism:volume>68</prism:volume>
    <prism:number>9</prism:number>
    <prism:startingPage>1144</prism:startingPage>
    <prism:endingPage>1157</prism:endingPage>
    <prism:category>empirical</prism:category>
    <prism:category>experiment</prism:category>
    <prism:category>measurement</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2439879">
    <title>Comments to the Paper: Briand, Eman, Morasca: On the Application of Measurement Theory in Software Engineering</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2439879</link>
    <description>&lt;i&gt;Empirical Software Engineering, Vol. 2, No. 3. (1997), pp. 313-316.&lt;/i&gt;</description>
    <dc:title>Comments to the Paper: Briand, Eman, Morasca: On the Application of Measurement Theory in Software Engineering</dc:title>

    <dc:creator>Horst Zuse</dc:creator>
    <dc:identifier>doi:10.1023/A:1009772101672</dc:identifier>
    <dc:source>Empirical Software Engineering, Vol. 2, No. 3. (1997), pp. 313-316.</dc:source>
    <dc:date>2008-02-28T05:11:13-00:00</dc:date>
    <prism:publicationYear>1997</prism:publicationYear>
    <prism:publicationName>Empirical Software Engineering</prism:publicationName>
    <prism:volume>2</prism:volume>
    <prism:number>3</prism:number>
    <prism:startingPage>313</prism:startingPage>
    <prism:endingPage>316</prism:endingPage>
    <prism:category>briand</prism:category>
    <prism:category>comments</prism:category>
    <prism:category>measurement</prism:category>
    <prism:category>theory</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2439803">
    <title>On the application of measurement theory in software engineering</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2439803</link>
    <description>&lt;i&gt;Empirical Software Engineering, Vol. 1, No. 1. (1 January 1996), pp. 61-88.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Elements of measurement theory have recently been introduced into the software engineering discipline. It has been suggested that these elements should serve as the basis for developing, reasoning about, and applying measures. For example, it has been suggested that software complexity measures should be additive, that measures fall into a number of distinct types (i.e., levels of measurement: nominal, ordinal, interval, and ratio), that certain statistical techniques are not appropriate for certain types of measures (e.g., parametric statistics for less-than-interval measures), and that certain transformations are not permissible for certain types of measures (e.g., non-linear transformations for interval measures). In this paper we argue that, inspite of the importance of measurement theory, and in the context of software engineering, many of these prescriptions and proscriptions are either premature or, if strictly applied, would represent a substantial hindrance to the progress of empirical research in software engineering. This argument is based partially on studies that have been conducted by behavioral scientists and by statisticians over the last five decades. We also present a pragmatic approach to the application of measurement theory in software engineering. While following our approach may lead to violations of the strict prescriptions and proscriptions of measurement theory, we demonstrate that in practical terms these violations would have diminished consequences, especially when compared to the advantages afforded to the practicing researcher.</description>
    <dc:title>On the application of measurement theory in software engineering</dc:title>

    <dc:creator>Lionel Briand</dc:creator>
    <dc:creator>Khaled Emam</dc:creator>
    <dc:creator>Sandro Morasca</dc:creator>
    <dc:identifier>doi:10.1007/BF00125812</dc:identifier>
    <dc:source>Empirical Software Engineering, Vol. 1, No. 1. (1 January 1996), pp. 61-88.</dc:source>
    <dc:date>2008-02-28T04:44:36-00:00</dc:date>
    <prism:publicationYear>1996</prism:publicationYear>
    <prism:publicationName>Empirical Software Engineering</prism:publicationName>
    <prism:volume>1</prism:volume>
    <prism:number>1</prism:number>
    <prism:startingPage>61</prism:startingPage>
    <prism:endingPage>88</prism:endingPage>
    <prism:category>empirical</prism:category>
    <prism:category>measurement</prism:category>
    <prism:category>theory</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2428610">
    <title>A Validation of Object-Oriented Design Metrics as Quality Indicators</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2428610</link>
    <description>&lt;i&gt;IEEE Trans. Softw. Eng., Vol. 22, No. 10. (October 1996), pp. 751-761.&lt;/i&gt;</description>
    <dc:title>A Validation of Object-Oriented Design Metrics as Quality Indicators</dc:title>

    <dc:creator>Victor Basili</dc:creator>
    <dc:creator>Lionel Briand</dc:creator>
    <dc:creator>Walc&#233;lio Melo</dc:creator>
    <dc:source>IEEE Trans. Softw. Eng., Vol. 22, No. 10. (October 1996), pp. 751-761.</dc:source>
    <dc:date>2008-02-26T07:07:54-00:00</dc:date>
    <prism:publicationYear>1996</prism:publicationYear>
    <prism:publicationName>IEEE Trans. Softw. Eng.</prism:publicationName>
    <prism:issn>0098-5589</prism:issn>
    <prism:volume>22</prism:volume>
    <prism:number>10</prism:number>
    <prism:startingPage>751</prism:startingPage>
    <prism:endingPage>761</prism:endingPage>
    <prism:publisher>IEEE Press</prism:publisher>
    <prism:category>empirical</prism:category>
    <prism:category>fault-proneness</prism:category>
    <prism:category>metrics</prism:category>
    <prism:category>quality</prism:category>
    <prism:category>validation</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2428601">
    <title>A Study on Fault-Proneness Detection of Object-Oriented Systems</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2428601</link>
    <description>&lt;i&gt;(2001)&lt;/i&gt;</description>
    <dc:title>A Study on Fault-Proneness Detection of Object-Oriented Systems</dc:title>

    <dc:creator>F Fioravanti</dc:creator>
    <dc:creator>P Nesi</dc:creator>
    <dc:source>(2001)</dc:source>
    <dc:date>2008-02-26T07:03:56-00:00</dc:date>
    <prism:publicationYear>2001</prism:publicationYear>
    <prism:publisher>IEEE Computer Society</prism:publisher>
    <prism:category>fault-proneness</prism:category>
    <prism:category>metrics</prism:category>
    <prism:category>prediction</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2424082">
    <title>Foundations of Software Measurement</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2424082</link>
    <description>&lt;i&gt;(1995)&lt;/i&gt;</description>
    <dc:title>Foundations of Software Measurement</dc:title>

    <dc:creator>Martin Shepperd</dc:creator>
    <dc:source>(1995)</dc:source>
    <dc:date>2008-02-25T02:57:38-00:00</dc:date>
    <prism:publicationYear>1995</prism:publicationYear>
    <prism:publisher>Prentice Hall</prism:publisher>
    <prism:category>measurement</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2424063">
    <title>Object-oriented design</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2424063</link>
    <description>&lt;i&gt;(1991)&lt;/i&gt;</description>
    <dc:title>Object-oriented design</dc:title>

    <dc:creator>Peter Coad</dc:creator>
    <dc:creator>Edward Yourdon</dc:creator>
    <dc:source>(1991)</dc:source>
    <dc:date>2008-02-25T02:44:03-00:00</dc:date>
    <prism:publicationYear>1991</prism:publicationYear>
    <prism:publisher>Yourdon Press</prism:publisher>
    <prism:category>cohesion</prism:category>
    <prism:category>coupling</prism:category>
    <prism:category>design</prism:category>
    <prism:category>object-oriented</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2396935">
    <title>Power-Laws in a Large Object-Oriented Software System</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2396935</link>
    <description>&lt;i&gt;Software Engineering, IEEE Transactions on, Vol. 33, No. 10. (2007), pp. 687-708.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;We present a comprehensive study of an implementation of the Smalltalk object oriented system, one of the first and purest object-oriented programming environment, searching for scaling laws in its properties. We study ten system properties, including the distributions of variable and method names, inheritance hierarchies, class and method sizes, system architecture graph. We systematically found Pareto - or sometimes log-normal - distributions in these properties. This denotes that the programming activity, even when modeled from a statistical perspective, can in no way be simply modeled as a random addition of independent increments with finite variance, but exhibits strong organic dependencies on what has been already developed. We compare our results with similar ones obtained for large Java systems, reported in the literature or computed by ourselves for those properties never studied before, showing that the behavior found is similar in all studied object oriented systems. We show how the Yule process is able to stochastically model the generation of several of the power-laws found, identifying the process parameters and comparing theoretical and empirical tail indexes. Lastly, we discuss how the distributions found are related to existing object-oriented metrics, like Chidamber and Kemerer's, and how they could provide a starting point for measuring the quality of a whole system, versus that of single classes. In fact, the usual evaluation of systems based on mean and standard deviation of metrics can be misleading. It is more interesting to measure differences in the shape and coefficients of the data?s statistical distributions.</description>
    <dc:title>Power-Laws in a Large Object-Oriented Software System</dc:title>

    <dc:creator>Giulio Concas</dc:creator>
    <dc:creator>Michele Marchesi</dc:creator>
    <dc:creator>Sandro Pinna</dc:creator>
    <dc:creator>Nicola Serra</dc:creator>
    <dc:identifier>doi:10.1109/TSE.2007.1019</dc:identifier>
    <dc:source>Software Engineering, IEEE Transactions on, Vol. 33, No. 10. (2007), pp. 687-708.</dc:source>
    <dc:date>2008-02-19T01:50:22-00:00</dc:date>
    <prism:publicationYear>2007</prism:publicationYear>
    <prism:publicationName>Software Engineering, IEEE Transactions on</prism:publicationName>
    <prism:volume>33</prism:volume>
    <prism:number>10</prism:number>
    <prism:startingPage>687</prism:startingPage>
    <prism:endingPage>708</prism:endingPage>
    <prism:category>empirical</prism:category>
    <prism:category>law</prism:category>
    <prism:category>power</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2390087">
    <title>Program development by stepwise refinement</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2390087</link>
    <description>&lt;i&gt;Commun. ACM, Vol. 14, No. 4. (April 1971), pp. 221-227.&lt;/i&gt;</description>
    <dc:title>Program development by stepwise refinement</dc:title>

    <dc:creator>Niklaus Wirth</dc:creator>
    <dc:identifier>doi:10.1145/362575.362577</dc:identifier>
    <dc:source>Commun. ACM, Vol. 14, No. 4. (April 1971), pp. 221-227.</dc:source>
    <dc:date>2008-02-17T05:06:21-00:00</dc:date>
    <prism:publicationYear>1971</prism:publicationYear>
    <prism:publicationName>Commun. ACM</prism:publicationName>
    <prism:issn>0001-0782</prism:issn>
    <prism:volume>14</prism:volume>
    <prism:number>4</prism:number>
    <prism:startingPage>221</prism:startingPage>
    <prism:endingPage>227</prism:endingPage>
    <prism:publisher>ACM</prism:publisher>
    <prism:category>8-queens</prism:category>
    <prism:category>education</prism:category>
    <prism:category>refinement</prism:category>
    <prism:category>stepwise</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2332956">
    <title>A vector-based approach to software size measurement and effort estimation</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2332956</link>
    <description>&lt;i&gt;Software Engineering, Transactions on, Vol. 27, No. 4. (2001), pp. 337-350.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Software size is a fundamental product measure that can be used for assessment, prediction and improvement purposes. However, existing software size measures, such as function points, do not address the underlying problem complexity of software systems adequately. This can result in disproportional measures of software size for different types of systems. We propose a vector size measure (VSM) that incorporates both functionality and problem complexity in a balanced and orthogonal manner. The VSM is used as the input to a vector prediction model (VPM) which can be used to estimate development effort early in the software life-cycle. We theoretically validate the approach against a formal framework. We also empirically validate the approach with a pilot study. The results indicate that the approach provides a mechanism to measure the size of software systems, classify software systems, and estimate development effort early in the software life-cycle to within &#177;20% across a range of application types</description>
    <dc:title>A vector-based approach to software size measurement and effort estimation</dc:title>

    <dc:creator>TE Hastings</dc:creator>
    <dc:creator>ASM Sajeev</dc:creator>
    <dc:identifier>doi:10.1109/32.917523</dc:identifier>
    <dc:source>Software Engineering, Transactions on, Vol. 27, No. 4. (2001), pp. 337-350.</dc:source>
    <dc:date>2008-02-05T02:10:40-00:00</dc:date>
    <prism:publicationYear>2001</prism:publicationYear>
    <prism:publicationName>Software Engineering, Transactions on</prism:publicationName>
    <prism:volume>27</prism:volume>
    <prism:number>4</prism:number>
    <prism:startingPage>337</prism:startingPage>
    <prism:endingPage>350</prism:endingPage>
    <prism:category>effort</prism:category>
    <prism:category>estimation</prism:category>
    <prism:category>measurement</prism:category>
    <prism:category>size</prism:category>
    <prism:category>vector</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2235025">
    <title>A solar system metaphor for 3D visualisation of object oriented software metrics</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2235025</link>
    <description>&lt;i&gt;(2004), pp. 53-59.&lt;/i&gt;</description>
    <dc:title>A solar system metaphor for 3D visualisation of object oriented software metrics</dc:title>

    <dc:creator>Hamish Graham</dc:creator>
    <dc:creator>Hong Yang</dc:creator>
    <dc:creator>Rebecca Berrigan</dc:creator>
    <dc:source>(2004), pp. 53-59.</dc:source>
    <dc:date>2008-01-15T13:38:25-00:00</dc:date>
    <prism:publicationYear>2004</prism:publicationYear>
    <prism:startingPage>53</prism:startingPage>
    <prism:endingPage>59</prism:endingPage>
    <prism:publisher>Australian Computer Society, Inc.</prism:publisher>
    <prism:category>3d</prism:category>
    <prism:category>metrics</prism:category>
    <prism:category>solar-system</prism:category>
    <prism:category>visualisation</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/984431">
    <title>Evaluating and tuning a static analysis to find null pointer bugs</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/984431</link>
    <description>&lt;i&gt;(2005), pp. 13-19.&lt;/i&gt;</description>
    <dc:title>Evaluating and tuning a static analysis to find null pointer bugs</dc:title>

    <dc:creator>David Hovemeyer</dc:creator>
    <dc:creator>Jaime Spacco</dc:creator>
    <dc:creator>William Pugh</dc:creator>
    <dc:identifier>doi:10.1145/1108792.1108798</dc:identifier>
    <dc:source>(2005), pp. 13-19.</dc:source>
    <dc:date>2006-12-08T13:39:19-00:00</dc:date>
    <prism:publicationYear>2005</prism:publicationYear>
    <prism:startingPage>13</prism:startingPage>
    <prism:endingPage>19</prism:endingPage>
    <prism:publisher>ACM Press</prism:publisher>
    <prism:category>analysis</prism:category>
    <prism:category>bugs</prism:category>
    <prism:category>dereference</prism:category>
    <prism:category>null</prism:category>
    <prism:category>pointer</prism:category>
    <prism:category>static</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2233693">
    <title>Static error detection using semantic inconsistency inference</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2233693</link>
    <description>&lt;i&gt;SIGPLAN Not., Vol. 42, No. 6. (June 2007), pp. 435-445.&lt;/i&gt;</description>
    <dc:title>Static error detection using semantic inconsistency inference</dc:title>

    <dc:creator>Isil Dillig</dc:creator>
    <dc:creator>Thomas Dillig</dc:creator>
    <dc:creator>Alex Aiken</dc:creator>
    <dc:identifier>doi:10.1145/1273442.1250784</dc:identifier>
    <dc:source>SIGPLAN Not., Vol. 42, No. 6. (June 2007), pp. 435-445.</dc:source>
    <dc:date>2008-01-15T05:45:55-00:00</dc:date>
    <prism:publicationYear>2007</prism:publicationYear>
    <prism:publicationName>SIGPLAN Not.</prism:publicationName>
    <prism:issn>0362-1340</prism:issn>
    <prism:volume>42</prism:volume>
    <prism:number>6</prism:number>
    <prism:startingPage>435</prism:startingPage>
    <prism:endingPage>445</prism:endingPage>
    <prism:publisher>ACM</prism:publisher>
    <prism:category>analysis</prism:category>
    <prism:category>c</prism:category>
    <prism:category>dereference</prism:category>
    <prism:category>detection</prism:category>
    <prism:category>err</prism:category>
    <prism:category>null</prism:category>
    <prism:category>static</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2227781">
    <title>Detecting indirect coupling</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2227781</link>
    <description>&lt;i&gt;Software Engineering Conference, 2005. Proceedings. 2005 Australian (2005), pp. 212-221.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Coupling is considered by many to be an important concept in measuring design quality There is still much to be learned about which aspects of coupling affect design quality or other external attributes of software. Much of the existing work concentrates on direct coupling, that is, forms of coupling that exists between entities that are directly related to each other. A form of coupling that has so far received little attention is indirect coupling, that is, coupling between entities that are not directly related. What little discussion there is in the literature suggests that any form of indirect coupling is simple the transitive closure of a form of direct coupling. We demonstrate that this is not the case, that there are forms of indirect coupling that cannot be represented in this way and suggest ways to measure it. We present a tool that identifies a particular form of indirect coupling that is integrated in the Eclipse IDE.</description>
    <dc:title>Detecting indirect coupling</dc:title>

    <dc:creator>Hong Yang</dc:creator>
    <dc:creator>E Tempero</dc:creator>
    <dc:creator>R Berrigan</dc:creator>
    <dc:identifier>doi:10.1109/ASWEC.2005.22</dc:identifier>
    <dc:source>Software Engineering Conference, 2005. Proceedings. 2005 Australian (2005), pp. 212-221.</dc:source>
    <dc:date>2008-01-14T00:05:54-00:00</dc:date>
    <prism:publicationYear>2005</prism:publicationYear>
    <prism:publicationName>Software Engineering Conference, 2005. Proceedings. 2005 Australian</prism:publicationName>
    <prism:startingPage>212</prism:startingPage>
    <prism:endingPage>221</prism:endingPage>
    <prism:category>analysis</prism:category>
    <prism:category>coupling</prism:category>
    <prism:category>eclipse</prism:category>
    <prism:category>indirect</prism:category>
    <prism:category>plugin</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2227773">
    <title>Measuring the Strength of Indirect Coupling</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2227773</link>
    <description>&lt;i&gt;Software Engineering Conference, 2007. ASWEC 2007. 18th Australian (2007), pp. 319-328.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;It is widely accepted that coupling plays an important role in software quality, particularly in the areas of software maintenance, so effort should be made to keep coupling levels to a minimum in order to reduce the complexity of the system. We have previously introduced the concept of &#34;indirect&#34; coupling - coupling formed by relationships/dependencies that are not directly evident - with the belief that high levels of indirect coupling can constitute greater costs to maintenance as it is harder to detect. In this paper we extend our previous studies by proposing metrics that can advance our understanding of the exact relationship between indirect coupling and maintainability. In particulars the metrics focus on the reflection of &#34;strength&#34; as it is a fundamental component of coupling. We present our observations on the results of applying the metrics to existing Java applications.</description>
    <dc:title>Measuring the Strength of Indirect Coupling</dc:title>

    <dc:creator>HY Yang</dc:creator>
    <dc:creator>E Tempero</dc:creator>
    <dc:identifier>doi:10.1109/ASWEC.2007.28</dc:identifier>
    <dc:source>Software Engineering Conference, 2007. ASWEC 2007. 18th Australian (2007), pp. 319-328.</dc:source>
    <dc:date>2008-01-14T00:03:29-00:00</dc:date>
    <prism:publicationYear>2007</prism:publicationYear>
    <prism:publicationName>Software Engineering Conference, 2007. ASWEC 2007. 18th Australian</prism:publicationName>
    <prism:startingPage>319</prism:startingPage>
    <prism:endingPage>328</prism:endingPage>
    <prism:category>coupling</prism:category>
    <prism:category>empirical</prism:category>
    <prism:category>indirect</prism:category>
    <prism:category>metrics</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/2190660">
    <title>Tracking bad apples: reporting the origin of null and undefined value errors</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/2190660</link>
    <description>&lt;i&gt;(2007), pp. 405-422.&lt;/i&gt;</description>
    <dc:title>Tracking bad apples: reporting the origin of null and undefined value errors</dc:title>

    <dc:creator>Michael Bond</dc:creator>
    <dc:creator>Nicholas Nethercote</dc:creator>
    <dc:creator>Stephen Kent</dc:creator>
    <dc:creator>Samuel Guyer</dc:creator>
    <dc:creator>Kathryn Mckinley</dc:creator>
    <dc:source>(2007), pp. 405-422.</dc:source>
    <dc:date>2008-01-03T05:56:01-00:00</dc:date>
    <prism:publicationYear>2007</prism:publicationYear>
    <prism:startingPage>405</prism:startingPage>
    <prism:endingPage>422</prism:endingPage>
    <prism:publisher>ACM</prism:publisher>
    <prism:category>analysis</prism:category>
    <prism:category>null</prism:category>
    <prism:category>program</prism:category>
    <prism:category>tracking</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/690278">
    <title>On the success of empirical studies in the international conference on software engineering</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/690278</link>
    <description>&lt;i&gt;(2006), pp. 341-350.&lt;/i&gt;</description>
    <dc:title>On the success of empirical studies in the international conference on software engineering</dc:title>

    <dc:creator>Carmen Zannier</dc:creator>
    <dc:creator>Grigori Melnik</dc:creator>
    <dc:creator>Frank Maurer</dc:creator>
    <dc:identifier>doi:10.1145/1134285.1134333</dc:identifier>
    <dc:source>(2006), pp. 341-350.</dc:source>
    <dc:date>2006-06-09T02:47:48-00:00</dc:date>
    <prism:publicationYear>2006</prism:publicationYear>
    <prism:startingPage>341</prism:startingPage>
    <prism:endingPage>350</prism:endingPage>
    <prism:publisher>ACM Press</prism:publisher>
    <prism:category>empirical</prism:category>
    <prism:category>icse</prism:category>
    <prism:category>study</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905019">
    <title>Indus project site</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905019</link>
    <description>&lt;i&gt;&lt;/i&gt;</description>
    <dc:title>Indus project site</dc:title>

    <dc:date>2007-11-13T01:52:31-00:00</dc:date>
    <prism:category>analysis</prism:category>
    <prism:category>bytecode</prism:category>
    <prism:category>framework</prism:category>
    <prism:category>java</prism:category>
    <prism:category>program</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905018">
    <title>Mining Version Histories to Guide Software Changes</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905018</link>
    <description>&lt;i&gt;(2004)&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;We apply data mining to version histories in order to guide programmers along related changes: &#34;Programmers who changed these functions also changed.... Given a set of existing changes, the mined association rules 1) suggest and predict likely further changes, 2) show up item coupling that is undetectable by program analysis, and 3) can prevent errors due to incomplete changes. After an initial change, our ROSE prototype can correctly predict further locations to be changed; the best predictive power is obtained for changes to existing software. In our evaluation based on the history of eight popular open source projects, ROSE's topmost three suggestions contained a correct location with a likelihood of more than 70 percent.</description>
    <dc:title>Mining Version Histories to Guide Software Changes</dc:title>

    <dc:creator>Thomas Zimmermann</dc:creator>
    <dc:creator>Peter Weissgerber</dc:creator>
    <dc:creator>Stephan Diehl</dc:creator>
    <dc:creator>Andreas Zeller</dc:creator>
    <dc:source>(2004)</dc:source>
    <dc:date>2007-11-13T01:52:31-00:00</dc:date>
    <prism:publicationYear>2004</prism:publicationYear>
    <prism:category>change</prism:category>
    <prism:category>coupling</prism:category>
    <prism:category>data</prism:category>
    <prism:category>mining</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905017">
    <title>Multithreaded Dependence Graphs for Concurrent Java Program</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905017</link>
    <description>&lt;i&gt;(1999)&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Understanding program dependencies in a computer program is essential for many software engineering activities including program slicing, testing, debugging, reverse engineering, and maintenance. In this paper, we present a dependence-based representation called the multithreaded dependence graph, which extends previous dependence-based representations, to represent program dependencies in a concurrent Java program. We also discuss some important applications of a multithreaded dependence graph in a maintenance environment for concurrent Java programs.</description>
    <dc:title>Multithreaded Dependence Graphs for Concurrent Java Program</dc:title>

    <dc:creator>Jianjun Zhao</dc:creator>
    <dc:source>(1999)</dc:source>
    <dc:date>2007-11-13T01:52:31-00:00</dc:date>
    <prism:publicationYear>1999</prism:publicationYear>
    <prism:publisher>IEEE Computer Society</prism:publisher>
    <prism:category>analysis</prism:category>
    <prism:category>concurrent</prism:category>
    <prism:category>dependence</prism:category>
    <prism:category>graph</prism:category>
    <prism:category>java</prism:category>
    <prism:category>program</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905016">
    <title>Dependence Analysis of Java Bytecode</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905016</link>
    <description>&lt;i&gt;(October 2000), pp. 486-491.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Understanding program dependencies in a computer program is essential for many software engineering tasks such as program understanding, testing, debugging, reverse engineering, and maintenance. In this paper, we present an approach to dependence analysis of Java bytecode, and discuss some applications of our technique, which include Java bytecode slicing, understanding, and testing.</description>
    <dc:title>Dependence Analysis of Java Bytecode</dc:title>

    <dc:creator>Jianjun Zhao</dc:creator>
    <dc:source>(October 2000), pp. 486-491.</dc:source>
    <dc:date>2007-11-13T01:52:31-00:00</dc:date>
    <prism:publicationYear>2000</prism:publicationYear>
    <prism:startingPage>486</prism:startingPage>
    <prism:endingPage>491</prism:endingPage>
    <prism:category>analysis</prism:category>
    <prism:category>bytecode</prism:category>
    <prism:category>dependence</prism:category>
    <prism:category>java</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905015">
    <title>Yesterday My Program worked. Today, It Does Not. Why?</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905015</link>
    <description>&lt;i&gt;(1999)&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Imagine some program and a number of changes. If none of these changes is applied (&#34;yesterday&#34;), the program works. If all changes are applied (&#34;today&#34;), the program does not work. Which change is responsible for the failure? We present an efficient algorithm that determines the minimal set of failure-inducing changes. Our delta debugging prototype tracked down a single failure-inducing change from 178,000 changed GDB lines within a few hours.</description>
    <dc:title>Yesterday My Program worked. Today, It Does Not. Why?</dc:title>

    <dc:creator>Andreas Zeller</dc:creator>
    <dc:source>(1999)</dc:source>
    <dc:date>2007-11-13T01:52:31-00:00</dc:date>
    <prism:publicationYear>1999</prism:publicationYear>
    <prism:category>analysis</prism:category>
    <prism:category>change</prism:category>
    <prism:category>debugging</prism:category>
    <prism:category>delta</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905014">
    <title>Hidden Dependencies in Program Comprehension and Change Propagation</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905014</link>
    <description>&lt;i&gt;(2001)&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Large software systems are difficult to understand and maintain. Program dependency analysis plays a key role in both understanding and maintenance. This paper discusses hidden dependencies among software components that make both understanding and maintenance hard. Hidden dependency is a relationship between two seemingly independent components and it is caused by a data flow inside of a third software components. The paper uses Abstract System Dependence Graphs to define hidden dependencies. It discusses the impact of hidden dependencies on the process of change propagation and also discusses an algorithm that warns about possible presence of hidden dependencies.</description>
    <dc:title>Hidden Dependencies in Program Comprehension and Change Propagation</dc:title>

    <dc:creator>Zhifeng Yu</dc:creator>
    <dc:creator>Vaclav Rajlich</dc:creator>
    <dc:source>(2001)</dc:source>
    <dc:date>2007-11-13T01:52:31-00:00</dc:date>
    <prism:publicationYear>2001</prism:publicationYear>
    <prism:publisher>IEEE Computer Society</prism:publisher>
    <prism:category>analysis</prism:category>
    <prism:category>change</prism:category>
    <prism:category>dependency</prism:category>
    <prism:category>hidden</prism:category>
    <prism:category>program</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905013">
    <title>Categorization of Common Coupling and Its Application to the Maintainability of the Linux Kernel</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905013</link>
    <description>&lt;i&gt;IEEE Trans. Software Eng., Vol. 30, No. 10. (2004), pp. 694-706.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Data coupling between modules, especially common coupling, has long been considered a source of concern in software design, but the issue is somewhat more complicated for products that are comprised of kernel modules together with optional nonkernel modules. This paper presents a refined categorization of common coupling based on definitions and uses between kernel and nonkernel modules and applies the categorization to a case study. Common coupling is usually avoided when possible because of the potential for introducing risky dependencies among software modules. The relative risk of these dependencies is strongly related to the specific definition-use relationships. In a previous paper, we presented results from a longitudinal analysis of multiple versions of the open-source operating system Linux. This paper applies the new common coupling categorization to version 2.4.20 of Linux, counting the number of instances of common coupling between each of the 26 kernel modules and all the other nonkernel modules. We also categorize each coupling in terms of the definition-use relationships. Results show that the Linux kernel contains a large number of common couplings of all types, raising a concern about the long-term maintainability of Linux.</description>
    <dc:title>Categorization of Common Coupling and Its Application to the Maintainability of the Linux Kernel</dc:title>

    <dc:creator>Liguo Yu</dc:creator>
    <dc:creator>Stephen Schach</dc:creator>
    <dc:creator>Kai 0003</dc:creator>
    <dc:creator>Jefferson Offutt</dc:creator>
    <dc:source>IEEE Trans. Software Eng., Vol. 30, No. 10. (2004), pp. 694-706.</dc:source>
    <dc:date>2007-11-13T01:52:31-00:00</dc:date>
    <prism:publicationYear>2004</prism:publicationYear>
    <prism:publicationName>IEEE Trans. Software Eng.</prism:publicationName>
    <prism:volume>30</prism:volume>
    <prism:number>10</prism:number>
    <prism:startingPage>694</prism:startingPage>
    <prism:endingPage>706</prism:endingPage>
    <prism:category>analysis</prism:category>
    <prism:category>common</prism:category>
    <prism:category>coupling</prism:category>
    <prism:category>longitudinal</prism:category>
    <prism:category>maintainability</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905012">
    <title>Structured Design: Fundamentals of a Discipline of Computer Program and System Design</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905012</link>
    <description>&lt;i&gt;(1979)&lt;/i&gt;</description>
    <dc:title>Structured Design: Fundamentals of a Discipline of Computer Program and System Design</dc:title>

    <dc:creator>Edward Yourdon</dc:creator>
    <dc:creator>Larry Constantine</dc:creator>
    <dc:source>(1979)</dc:source>
    <dc:date>2007-11-13T01:52:31-00:00</dc:date>
    <prism:publicationYear>1979</prism:publicationYear>
    <prism:publisher>Prentice-Hall</prism:publisher>
    <prism:category>cohesion</prism:category>
    <prism:category>coupling</prism:category>
    <prism:category>design</prism:category>
    <prism:category>modularity</prism:category>
    <prism:category>structured</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905011">
    <title>An Empirical Validation of Complexity Profile Graph</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905011</link>
    <description>&lt;i&gt;(2005)&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;This paper presents the results of an empirical study carried out to investigate if the complexity profile graph (CPG) is related with one of the predicators of software complexity measures, such as response time and error rate, and thus could be used as a valid indicator of program comprehensibility. Lower and upper division computer science and software engineering students were asked to respond to questions regarding the execution of a source code module written in JAVA and understanding the fundamental goal of each part of the source code. The response time for each question and the correctness of each response were recorded. The statistical analysis of the experimental data reports that there is a positive linear correlation between the CPG and the time taken to respond correctly to each question. In addition, the paper discusses if there is any effect of the control structure diagram (CSD) on measuring the difficulty of program comprehensibility.</description>
    <dc:title>An Empirical Validation of Complexity Profile Graph</dc:title>

    <dc:creator>Jeong Yang</dc:creator>
    <dc:creator>Dean Hendrix</dc:creator>
    <dc:creator>Kai Chang</dc:creator>
    <dc:creator>David Umphress</dc:creator>
    <dc:source>(2005)</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>2005</prism:publicationYear>
    <prism:category>complexity</prism:category>
    <prism:category>empirical</prism:category>
    <prism:category>metric</prism:category>
    <prism:category>validation</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905008">
    <title>Dependence Analysis for Recursive Java Programs</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905008</link>
    <description>&lt;i&gt;ACM SIGPLAN, Vol. 36 (2001), pp. 70-76.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Dependence analysis is an important approach to analyzing, understanding, testing and maintaining programs. This paper develops a new kind of dependence analysis method for recursive Java programs. In our method, the program dependence graph (PDG) of a Java program consists of a set of PDGs that are not connected. They interact with each other by dependences among parameters. Thus, he inter-function dependence analysis is transformed to intra-function dependence analysis. Based on this model, we develop a new approach to analyze dependences of a direct or indirect recursive Java program by simulating its execution.</description>
    <dc:title>Dependence Analysis for Recursive Java Programs</dc:title>

    <dc:creator>Baowen Xu</dc:creator>
    <dc:creator>Zheniang Chen</dc:creator>
    <dc:source>ACM SIGPLAN, Vol. 36 (2001), pp. 70-76.</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>2001</prism:publicationYear>
    <prism:publicationName>ACM SIGPLAN</prism:publicationName>
    <prism:volume>36</prism:volume>
    <prism:startingPage>70</prism:startingPage>
    <prism:endingPage>76</prism:endingPage>
    <prism:category>analysis</prism:category>
    <prism:category>dependence</prism:category>
    <prism:category>java</prism:category>
    <prism:category>recursive</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905007">
    <title>Evaluating Software Complexity Measures</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905007</link>
    <description>&lt;i&gt;IEEE Transactions on Software Engineering, Vol. 14, No. 9. (September 1988), pp. 1357-1365.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;A set of properties of syntactic software complexity measures is proposed to serve as a basis for the evaluation of such measures. Four known complexity measures are evaluated and compared using these criteria. This formalized evaluation clarifies the strengths and weaknesses of the examined complexity measures, which include the statement count, cyclomatic number, effort measure, and data flow complexity measures. None of these measures possesses all nine properties, and several are found to fail to possess particularly fundamental properties; this failure calls into question their usefulness in measuring synthetic complexity.</description>
    <dc:title>Evaluating Software Complexity Measures</dc:title>

    <dc:creator>Elaine Weyuker</dc:creator>
    <dc:source>IEEE Transactions on Software Engineering, Vol. 14, No. 9. (September 1988), pp. 1357-1365.</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>1988</prism:publicationYear>
    <prism:publicationName>IEEE Transactions on Software Engineering</prism:publicationName>
    <prism:volume>14</prism:volume>
    <prism:number>9</prism:number>
    <prism:startingPage>1357</prism:startingPage>
    <prism:endingPage>1365</prism:endingPage>
    <prism:category>complexity</prism:category>
    <prism:category>empirical</prism:category>
    <prism:category>metric</prism:category>
    <prism:category>validation</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905006">
    <title>The Cost of Data Flow Testing: An Empirical Study</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905006</link>
    <description>&lt;i&gt;IEEE Transactions on Software Engineering, Vol. 16, No. 2. (1990), pp. 121-128.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;A family of test data adequacy criteria employing data-flow information was previously proposed, and a theoretical complexity analysis was performed. The author describes an empirical study to determine the actual cost of using these criteria. The aim is to establish the practical usefulness of these criteria in testing software and provide a basis for predicting the amount of testing needed for a given program. The first goal of the study is to confirm the belief that the family of software testing criteria considered is practical to use. An attempt is made to show that even as the program size increases, the amount of testing, expressed in terms of the number of test cases sufficient to satisfy a given criterion, remains modest. Several ways of evaluating this hypothesis are explored. The second goal is to provide the prospective user of these criteria with a way of predicting the number of test cases that will be needed to satisfy a given criterion for a given program. This provides testers with a basis for selecting the most comprehensive criterion that they can expect to satisfy. Several plausible bases for such a prediction are considered.</description>
    <dc:title>The Cost of Data Flow Testing: An Empirical Study</dc:title>

    <dc:creator>EJ Weyuker</dc:creator>
    <dc:source>IEEE Transactions on Software Engineering, Vol. 16, No. 2. (1990), pp. 121-128.</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>1990</prism:publicationYear>
    <prism:publicationName>IEEE Transactions on Software Engineering</prism:publicationName>
    <prism:volume>16</prism:volume>
    <prism:number>2</prism:number>
    <prism:startingPage>121</prism:startingPage>
    <prism:endingPage>128</prism:endingPage>
    <prism:publisher>IEEE Computer Society</prism:publisher>
    <prism:category>data</prism:category>
    <prism:category>empirical</prism:category>
    <prism:category>flow</prism:category>
    <prism:category>study</prism:category>
    <prism:category>testing</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905005">
    <title>Program Slicing</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905005</link>
    <description>&lt;i&gt;IEEE Trans. Software Eng., Vol. 10, No. 4. (1984), pp. 352-357.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Program slicing is a method used by experienced computer programmers for abstracting from programs. Starting from a subset of a program's behavior, slicing reduces that program to a minimal form which still produces that behavior. The reduced program, called a &#34;slice&#34;, is an independent program guaranteed to faithfully represent the original program within the domain of the specified subset of behavior. Finding a slice is in general unsolvable. A dataflow algorithm is presented for approximating slices when the behavior subset is specified as the values of a set of variables at a statement. Experimental evidence is presented that these slices are used by programmers during debugging. Experience with two automatic slicing tools is summarized. New measures of program complexity are suggested based on the organization of a program's slices.</description>
    <dc:title>Program Slicing</dc:title>

    <dc:creator>Mark Weiser</dc:creator>
    <dc:source>IEEE Trans. Software Eng., Vol. 10, No. 4. (1984), pp. 352-357.</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>1984</prism:publicationYear>
    <prism:publicationName>IEEE Trans. Software Eng.</prism:publicationName>
    <prism:volume>10</prism:volume>
    <prism:number>4</prism:number>
    <prism:startingPage>352</prism:startingPage>
    <prism:endingPage>357</prism:endingPage>
    <prism:category>analysis</prism:category>
    <prism:category>original</prism:category>
    <prism:category>program</prism:category>
    <prism:category>slicing</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905004">
    <title>An Extension to Robustness Slicing Algorithm Based on Dynamic Array</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905004</link>
    <description>&lt;i&gt;(JanuarySeptember-February0 June 2006), pp. 77-84.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Since it was introduced in 1979, program slicing has been used widely in many aspects of software engineering, such as code debugging, program comprehension, software maintenance and reverse engineering etc. Since 1995, many people have studied and developed some methods and tools to help programmers use program slicing technique in software testing, and some valuable results have been obtained by theoretic and empirical analysis and evaluation. Research results show that program slicing is very useful for regression testing and simplifying testing. In this article, we try to extend the ability of Harman and Danicics robust slicing algorithm by considering how to deal with dynamically allocated storage. Especially, we discuss how to compute the robustness slice when the subscripts of an array are dynamic.</description>
    <dc:title>An Extension to Robustness Slicing Algorithm Based on Dynamic Array</dc:title>

    <dc:creator>Yancheng Wang</dc:creator>
    <dc:creator>Bixin Li</dc:creator>
    <dc:creator>Xufang Gong</dc:creator>
    <dc:source>(JanuarySeptember-February0 June 2006), pp. 77-84.</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>2006</prism:publicationYear>
    <prism:startingPage>77</prism:startingPage>
    <prism:endingPage>84</prism:endingPage>
    <prism:category>dynamic</prism:category>
    <prism:category>program</prism:category>
    <prism:category>robustness</prism:category>
    <prism:category>slicing</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905003">
    <title>The Java system dependence graph</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905003</link>
    <description>&lt;i&gt;(2003)&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;The Program Dependence Graph was introduced by Ottenstein and Ottenstein in 1984. It was suggested to be a suitable internal program representation for monolithic programs, for the purpose of carrying out certain software engineering operations such as slicing and the computation of program metrics. Since then, Horwitz et al. have introduced the multi-procedural equivalent System Dependence Graph. Several authors have proposed object-oriented dependence graph construction approaches. Every approach provides its own benefits, some of which are language specific. This paper presents a Java System Dependence Graph which draws on the strengths of a range of earlier works and adapts them, if necessary, to the Java language. It also provides guidance on the construction of the graph, identifies potential research topics based on it and shows, in the appendix, a completed graph with a slice highlighted for a small, but realistic example.</description>
    <dc:title>The Java system dependence graph</dc:title>

    <dc:creator>M Walkinshaw</dc:creator>
    <dc:creator>M Roper</dc:creator>
    <dc:source>(2003)</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>2003</prism:publicationYear>
    <prism:category>dependence</prism:category>
    <prism:category>graph</prism:category>
    <prism:category>java</prism:category>
    <prism:category>system</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905002">
    <title>The semantic approach to program slicing</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905002</link>
    <description>&lt;i&gt;(1991), pp. 107-119.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Program slicing is a source-to-source transformation that has applications in construction, analysis, testing and debugging of programs. A program slice contains the portion of a program that captures some subset of the program behavior. Algorithms are available for constructing slices for a particular execution of a program (dynamic slices) as well as to approximate a subset of the behavior over all possible executions of a program (static slices). As the behavior of a program is determined by the semantics of the language, it is reasonable to expect a semantic justification for the practice of program slicing, Program slices have been used in several applications but there is no single notion of a slice that is useful for all applications. This paper identifies and categorizes different notions of a program slice available in the literature as well as several new notions. The various notions are formalized in a denotational framework. Extending the work by Cartwright and Felleisen [2] on the semantics of program dependence, a semantic justification is provided for the process of program slicing using program dependence graphs.</description>
    <dc:title>The semantic approach to program slicing</dc:title>

    <dc:creator>GA Venkatesh</dc:creator>
    <dc:source>(1991), pp. 107-119.</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>1991</prism:publicationYear>
    <prism:startingPage>107</prism:startingPage>
    <prism:endingPage>119</prism:endingPage>
    <prism:publisher>ACM Press</prism:publisher>
    <prism:category>analysis</prism:category>
    <prism:category>program</prism:category>
    <prism:category>semantic</prism:category>
    <prism:category>slicing</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905001">
    <title>Taming the Complexity of STE-based Design Verification Using Program Slicing</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905001</link>
    <description>&lt;i&gt;(Nov. 2006), pp. 137-142.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;This paper presents the development of a hierarchical methodology for speeding-up a symbolic trajectory evaluation (STE) based verification flow, using &#34;program slicing&#34; techniques. An overview of the proposed methodology is described, along with the details of a prototype tool that has been developed to automate the approach. The tool, called FACTOR, has been successfully applied to reduce the size of the RTL implementation of a floating-point unit in an Intelreg Pentiumreg 4 processor model needed for formally verifying an embedded module. The existing proof specification for the module was validated using Forte, Intel's STE tool, on both the original and the reduced model. A comparison of the results demonstrates the effectiveness of the methodology, and its immense potential to scale up the verification flow to larger design sizes</description>
    <dc:title>Taming the Complexity of STE-based Design Verification Using Program Slicing</dc:title>

    <dc:creator>VM Vedula</dc:creator>
    <dc:creator>FL Andersen</dc:creator>
    <dc:creator>JA Abraham</dc:creator>
    <dc:source>(Nov. 2006), pp. 137-142.</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>2006</prism:publicationYear>
    <prism:startingPage>137</prism:startingPage>
    <prism:endingPage>142</prism:endingPage>
    <prism:category>program</prism:category>
    <prism:category>slicing</prism:category>
    <prism:category>ste</prism:category>
    <prism:category>verification</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1905000">
    <title>Soot - a Java bytecode optimization framework</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1905000</link>
    <description>&lt;i&gt;(1999)&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;This paper presents Soot, a framework for optimizing Java bytecode. The framework is implemented in Java and supports three intermediate representations for representing Java bytecode: Baf, a streamlined representation of bytecode which is simple to manipulate; Jimple, a typed 3-address intermediate representation suitable for optimization; and Grimp, an aggregated version of Jimple suitable for decompilation. We describe the motivation for each representation, and the salient points in translating from one representation to another. In order to demonstrate the usefulness of the framework, we have implemented intraprocedural and whole program optimizations. To show that whole program bytecode optimization can give performance improvements, we provide experimental results for 12 large benchmarks, including 8 SPECjvm98 benchmarks running on JDK 1.2 for GNU/Linux. These results show up to 8 improvement when the optimized bytecode is run using the interpreter and up to 21% when run using the JIT compiler.</description>
    <dc:title>Soot - a Java bytecode optimization framework</dc:title>

    <dc:creator>Vallee Rai</dc:creator>
    <dc:creator>Phong</dc:creator>
    <dc:creator>C Etienne</dc:creator>
    <dc:creator>G Laurie</dc:creator>
    <dc:creator>H Patrick</dc:creator>
    <dc:creator>L Vijay</dc:creator>
    <dc:source>(1999)</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>1999</prism:publicationYear>
    <prism:category>bytecode</prism:category>
    <prism:category>java</prism:category>
    <prism:category>optimization</prism:category>
    <prism:category>soot</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1904999">
    <title>The impact of inheritance depth on maintenance tasks --- Detailed description and evaluation of two experiment replications</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1904999</link>
    <description>&lt;i&gt;(1998)&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;Inheritance is one of the main concepts of object-oriented technology. It is claimed that the use of inheritance improves productivity and decreases development time. John Daly et al. reported on two experiments evaluating the effects of inheritance depth on program maintenance. They found that maintenance was performed significantly quicker for software using three levels of inheritance, compared to equivalent flattened software without inheritance. A second experiment found that maintenance for software using five levels of inheritance tended to be slightly slower than for equivalent software without inheritance. We report on similar experiments on the same question. Our results contradict those mentioned above. Several crucial changes were made to the setup. In particular longer and more complex programs were used, an inheritance diagram was available to the subjects, and we used more and different kinds of maintenance tasks. Furthermore, our experiment design compares zero level, three level and five level inheritance directly in one experiment. The results suggest that there is a tendency that deeper inheritance may complicate program understanding. But the effect depends rather on other factors such as complexity of the program and type of maintenance task than on inheritance depth. We found a high correlation between maintenance time and the number of methods to trace to gain program understanding. Further work should be done to identify other influence factors.</description>
    <dc:title>The impact of inheritance depth on maintenance tasks --- Detailed description and evaluation of two experiment replications</dc:title>

    <dc:creator>Barbara Unger</dc:creator>
    <dc:creator>Lutz Prechelt</dc:creator>
    <dc:source>(1998)</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>1998</prism:publicationYear>
    <prism:category>experiment</prism:category>
    <prism:category>inheritance</prism:category>
    <prism:category>maintenance</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1904998">
    <title>Javari: adding reference immutability to Java</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1904998</link>
    <description>&lt;i&gt;SIGPLAN Not., Vol. 40, No. 10. (2005), pp. 211-230.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;This paper describes a type system that is capable of expressing and enforcing immutability constraints. The specific constraint expressed is that the abstract state of the object to which an immutable reference refers cannot be modified using that reference. The abstract state is (part of) the transitively reachable state: that is, the state of the object and all state reachable from it by following references. The type system permits explicitly excluding fields from the abstract state of an object. For a statically type-safe language, the type system guarantees reference immutability. If the language is extended with immutability downcasts, then run-time checks enforce the reference immutability constraints.This research builds upon previous research in language support for reference immutability. Improvements that are new in this paper include distinguishing the notions of assignability and mutability; integration with Java 5's generic types and with multi-dimensional arrays; a mutability polymorphism approach to avoiding code duplication; type-safe support for reflection and serialization; and formal type rules and type soundness proof for a core calculus. Furthermore, it retains the valuable features of the previous dialect, including usability by humans (as evidenced by experience with 160,000 lines of Javari code) and interoperability with Java and existing JVMs.</description>
    <dc:title>Javari: adding reference immutability to Java</dc:title>

    <dc:creator>Matthew Tschantz</dc:creator>
    <dc:creator>Michael Ernst</dc:creator>
    <dc:source>SIGPLAN Not., Vol. 40, No. 10. (2005), pp. 211-230.</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>2005</prism:publicationYear>
    <prism:publicationName>SIGPLAN Not.</prism:publicationName>
    <prism:volume>40</prism:volume>
    <prism:number>10</prism:number>
    <prism:startingPage>211</prism:startingPage>
    <prism:endingPage>230</prism:endingPage>
    <prism:publisher>ACM Press</prism:publisher>
    <prism:category>immutability</prism:category>
    <prism:category>java</prism:category>
    <prism:category>reference</prism:category>
</item>



<item rdf:about="http://www.citeulike.org/user/swiftwatch/article/1904997">
    <title>Static analysis of students' Java programs</title>
    <link>http://www.citeulike.org/user/swiftwatch/article/1904997</link>
    <description>&lt;i&gt;(2004), pp. 317-325.&lt;/i&gt;&lt;br /&gt;&lt;br /&gt;A recent industry survey (Townhidnejad and Hilburn, 2002) has reported that more than fifty percent of a software project's budget is spent on activities related to improving software quality. Industry leaders claim that this is caused by the inadequate attention paid to software quality in the development phase. This paper introduces a static analysis framework which can be used to give beginning students practice in writing better quality Java programs and to assist teaching staff in the marking process. The framework uses both software engineering metrics and relative comparison to judge the quality of student's programs and provide feedback about how solutions might be improved.</description>
    <dc:title>Static analysis of students' Java programs</dc:title>

    <dc:creator>Nghi Truong</dc:creator>
    <dc:creator>Paul Roe</dc:creator>
    <dc:creator>Peter Bancroft</dc:creator>
    <dc:source>(2004), pp. 317-325.</dc:source>
    <dc:date>2007-11-13T01:52:30-00:00</dc:date>
    <prism:publicationYear>2004</prism:publicationYear>
    <prism:startingPage>317</prism:startingPage>
    <prism:endingPage>325</prism:endingPage>
    <prism:publisher>Australian Computer Society, Inc.</prism:publisher>
    <prism:category>analysis</prism:category>
    <prism:category>java</prism:category>
    <prism:category>static</prism:category>
    <prism:category>students</prism:category>
</item>



</rdf:RDF>

