Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools


This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
research:cultivate:towards_benchmarks [2015/10/28 12:36] external edit
research:cultivate:towards_benchmarks [2018/05/09 01:59] (current)
Line 1: Line 1:
 +====== Towards Benchmarks ======
 +Yesterday (05.05.10) I (dsp) was reminded that we don't have many benchmarks for smell detection available. Here is what I'm currently aware of. All the samples contain bad smells although they are not annotated. ... and these projects are small. Still it's worth to make a beginning :-).
 +  * Marting Fowler
 +    * The video store example from his seminal [[http://​​books.html#​refactoring|Refactoring]] book. ([[http://​​home/​Projects/​Entries/​2008/​4/​13_Photo_of_the_Day.html|The code can be found here]])
 +    * He elaborated a [[http://​​rejectedExample.pdf|longer example]] that got rejected for the book, but is of course even more interesting as a benchmark for us. ({{:​research:​cultivate:​|Code}}((Extracted from the PDF. Made some minor corrections to get it to compile. Permission to publish given by M. Fowler.)))
 +  * William C. Wake
 +    * [[http://​​xplor/#​Programming%20-%20Refactoring|Short articles discussing refactoring examples]]
 +    * [[http://​​rwb/​|Refactoring Workbook]]
 +  * [[http://​​10.1109/​IWPSE.2005.30|The LAN-simulation:​ A Refactoring Teaching Example]]
 +    * Serge Demeyer, Filip Van Rysselberghe,​ Tudor Girba, Jacek Ratzinger, Radu Marinescu, Tom Mens, Bart Du Bois, Dirk Janssens, Stephane Ducasse, Michele Lanza, Matthias Rieger, Harald Gall, Mohammad El-Ramly((The authors propose this example as a benchmark!)):​ The LAN-simulation:​ A Refactoring Teaching Example. Principles of Software Evolution, International Workshop on, pp. 123-134, Eighth International Workshop on Principles of Software Evolution (IWPSE'​05),​ 2005.
 +    * http://​​Research/​Artefacts/​refactoringLabSession/​
 +    * Smell: Code duplication -> Refactoring:​ Extract method
 +    * Smell: Feature envy -> Refactoring:​ Move method
 +  * [[three_key_cup_app| The "Three Key Cup App" for Refactoring exercises]] {{https://​​_media/​teaching/​labs/​xp/​2005a/​|}}
 +    * Smell: Feature envy -> Refactoring:​ Move method
 +    * Smell: Code duplication -> Refactoring:​ (here) Tease apart Inheritance,​ Introduce State Pattern
 +    * Smell: Dependency cycle -> Refactoring:​ Introduce Observer Pattern
 +  * Refactoring exercise from our Object Oriented Software Construction lecture, "​Rectangle"​
 +    * [[https://​​teaching/​lectures/​oosc/​2009/​assignment_9#​task_23refactoring|Task and code]]
 +    * Smell: Feature envy -> Extract + move method
 +    * Smell: Comments (in method body telling the "​what"​ not the "​why"​) -> Extract method
 +    * Smell: Code duplication -> Extract method
 +    * Smell: Dependency cycle -> Extract Interface & Use Super type where possible
 +    * [[benchmark refactoring exercise rectangle|"​Benchmark"​ results]]: :-( :-| :-| :-) :-( 
 +  * [[http://​​p/​cohesion-tests/​|Cohesion-tests]] - A collection of Java test classes for use in evaluating object-oriented cohesion metrics. ​
 +    * Desription: "This project provides a collection of Java test classes for use in evaluating object-oriented cohesion metrics. The classes vary in the amounts of connectivity within the classes'​ members, and in the types of connectivity. These classes should also be useful in evaluating the effectiveness of automated Extract Class refactoring tools."​
 +    * Examples developed/​collected by [[http://​​~kcassell/​|Keith Cassell]].
 +    * Not yet explored further by us.
 +  * Premature Over- Under-design
 +    * Not so few Java programmers tend to create artificial complexity((They seem to feel "the urge to add complexity because “someday we’ll need it, I just know it!”, or because “it’s not sufficiently flexible enough” or “we need reusability in our code” or (God help us!) because it’s “cool”"​. See the blog post.)) in their code. Unfortunately removing this complexity seems to be even harder than removing the standard smells.
 +    * William Woody gives an excellent idea about how this kind of code feels in [[http://​​blog/?​p=622|his blog post "How (not) to write Factorial in Java."​]]
 +    * My (dsp) candidate name for the smells that would detect this artifical complexity is "​[[http://​​wiki/​Occam%27s_razor|Occams razor]] set".
 +  * Further Candidates (Not explored further)
 +    * http://​​portal/​web/​csdl/​doi/​10.1109/​WCRE.2009.23 - Reports about God Classes in Open Source projects.
 +    * http://​​ - A project to compare the implementation of one application in different languages.
 +    * http://​​index.html - Aimed at exploring the open source phenomenon through the use of code analysis.
 +    * http://​​ - A curated collection of software systems intended to be used for empirical studies of code artefacts
 +    * http://​​docs/​pangea - Was created as a complement to the Qualitas Corpus project.
 +    * http://​​qualitas.class/​ - Compiled version of the Qualitas Corpus.
 +    * http://​​tools/​designsmells/​index_html#​2 - Anti-Pattern - Micro-Architecture Repository, database of occurrences of code and design smells.
 +  * Focused on design patterns, might nevertheless be useful for reference:
 +    * http://​​tools/​designpatterns/​index_html#​2 - Pattern-like Micro-Architecture Repository
 +    * http://​​DPBWeb/​ - Design Pattern detection tools Benchmark platform ​

SEWiki, © 2020