-
- The Prototype
-
-
- Research
Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering
![]() |
Picture of a dahlia. Created by Ramin Nakisa. Dahlias have already been cultivated by the Aztecs. |
---|
Some “smells” are only relevant for a certain culture. As an example we implemented four smells derived from the Android Performance Guidelines:
In other contexts preferring static over virtual methods must be seen as serious smell, but for performance on Android devices it has a major benefit. The other three criteria could be used for other context as well but are not very important there.
The layout of the overview pyramid was improved. Hints explain the metrics. This is essential for beginners, especially for the ratios of two metrics.
All Cultivate views are separated into the two categories “Cultivate” and “Cultivate (Experimental)”. Views of the first category should run stable, have a nice look and feel and provide a help.
This version of Cultivate includes a new implementation of the package dependencies diagramm view, which is now completely based on the zest 2.0 framework. The visually improved diagram includes several new features.
The Metric and Smell Result view was rewritten from scratch. It now additionally features a filterable tree selection of metrics and smells and shows also partial results.
The Term Cloud View was updated to use the new Cloudio feature from Zest 2.0. This improved the visualization of the cloud and the flexibility of the view, e.g. it now also allows scaling.
As a new experimental view, Cultivate allows visualization of defined concept structures in form of a graph. It further allows to filter on node types. As this view is still experimental, only a small development set of structures is provided in Cultivate and no documentation is available.
With the focus on a Cultivate diagram view, one can open its corresponding help text simply by using the Eclipse help. A help text illuminates the purpose of its view and how to use its possible features.
The Generic Table View allows the developer to query arbitrary Prolog predicates directly. The results are displayed as a sorted table which can be exported for further reference in various formats e.g. CSV with semicolon separated data. The query results will update automatically with every change of the java code with no need for the developer to initialize a new query.
The stability was improved through an enhanced CultivateViewPart, providing change listening and prolog querying functionality. Also the initialization and updating of our internal prolog interface (aka Repository) was improved.